Someone on your delivery team wants one more column on the risk register: an owner field, say, so every project captures who is carrying each risk. On most provisioning setups that one-line request is not a one-line change. It is a ticket, a scheduled release, and a person with elevated rights regenerating and republishing the template the whole organization provisions from. A field a project manager could describe in a sentence becomes a change only IT can make.
It works that way because of what the template actually is. In the classic SharePoint provisioning route the template is a generated artifact, a package of scripted instructions produced by a tool and run with PowerShell. You do not edit it the way you edit a site. You regenerate it, and the regenerated version arrives as a new artifact with a new identifier and freshly generated code, so anything pointing at the old one has to be repointed. The cost of the change is not the column. It is the machinery that has to move to carry the column.
The template that is really a program
This is the part worth being clear-eyed about, because it stays invisible until you need to change something. A scripted template is software. Updating a single list column means someone opens the tooling, changes the definition, regenerates the package, tests it, and republishes
it, and until they do, every new project keeps provisioning the old shape. The people who feel the gap, your project managers, are not the people who can close it. So the column waits, or the register quietly grows a fifth spreadsheet nobody provisioned at all.
Ours is a site you open and edit
ProjectPoint takes the opposite approach, and it is the load-bearing design decision in the whole product. The golden template is not a package. It is a real, live SharePoint site, sitting in your own tenant, that your project manager maintains like any other site they own. Want another column on the risk register, a different default folder structure, a new content type, a tidier set of libraries? Change it on the golden site the way you would change any site. There is no build step, because there is nothing to build. The site is the template.
When the next project asks for a workspace, the provisioning engine copies that golden site, as it stands that day, into the new project's own site. The improved register is simply there, because it was there on the golden site when the copy ran. No ticket, no republish, no new identifier to repoint, and no waiting for a release window. Editing a site is something a project manager already knows how to do, and that is precisely the skill the design leans on.
Who holds the pen
The quiet shift here is about ownership, not features. On the scripted route, the shape of every future project site is held by whoever owns the provisioning code, which is almost always IT. On this one, it is held by whoever maintains the golden site, which is your PMO. The people
who actually run projects decide what a project workspace contains, and they change it themselves, in the tool they already use, on the afternoon they decide to, without anyone re-architecting a provisioning engine because a column moved.
That is why the list of what the golden site carries is worth knowing: its site features, its permissions, its content types and site columns, its lists and libraries, its navigation, and its default folder content. Every one of those is edited the same way, on the golden site, by the same person, and it is cloned into the next project exactly as it stands. The column is just the smallest example of a much larger pen you are being handed.
The one limit we will not dress up
There is a real boundary here and you should hear it from us rather than find it in month nine. Improving the golden site changes every project provisioned after the change. It does not reach back. A site created in month one does not receive month nine's new column, and there is no drift detection and no re-apply to already-provisioned sites today. If a change has to land in sites that already exist, that is manual work, project by project, and it is the largest structural limit in the current design.
The honest other half is the half this post is about: making the change itself is trivial and takes effect on the very next provisioning run. The gap is retroactive application to old sites, not the cost of holding the pen. Most teams edit the template often in the first months and rarely once it settles, which is exactly the shape this design handles well.
Get in touch, and we will show you the golden site, and let you add the column yourself.
