The Register That Still Knows Where Everything Is

08.09.26 10:00 AM

Six months into the year, someone asks a simple question: where does the Henderson project keep its documents? If your project sites were built by hand, the honest answer is a search, a guess, and a message to whoever set it up, if they are still here. The site exists. The board exists. The register of risks exists. What does not exist is one place that reliably knows they all do, and how to get to each one.

That is the quiet failure of building sites one at a time. Each one is fine on the day it is made. But nothing holds the list of them all, so the map of your portfolio lives in people's heads and in half-remembered links, and it degrades a little with every project, every reorg, and every person who leaves. The problem was never making a project site. It was keeping a growing pile of them findable.

Making the site is the easy part

Provisioning a workspace is a one-time act. Keeping a portfolio of workspaces navigable, so any project can be found by someone who did not set it up, is the ongoing one, and it is the part hand-built sites never solve. A folder of bookmarks is not a map. A Teams message asking "what was the site for Henderson again" is the sound of the map having failed.

The register is the index, and it links back

ProjectPoint's answer is that the Projects list is not just where projects are started; it is the index that stays current by construction. When a project is provisioned, its record links itself back to the new site and to its Planner board. The register does not drift out of date, because the linking is part of the same run that creates the site, not a step someone has to remember afterwards. To find any project, you open the register, find the row, and follow the link. The list that starts your projects is the same list that always knows where they went.

The hub routes people, in your own navigation

Findability is not only the register's job. Each new project site joins your hub, and the hub navigation updates so the project appears where people already look, with audience targeting so they see the projects that are actually theirs rather than everyone's. The homepage is generated with the project's own details filled in, so a person opening a project for the first time lands somewhere oriented instead of on an empty site they have to decode. The map is not a document you maintain. It is the way the sites were built.

Why this is the part you buy first

This is the entry tier of a project management platform, and it is deliberately the foundation. The registry and the provisioning engine are the component that is built, demonstrable, and buyable today, and the reason they come first is that everything else the platform adds, the

risk and decision registers, the time and budget capture, the reporting on top, is only worth putting inside a project site if the project site can be found later. The map has to hold before the things on the map are worth drawing.

The limit worth stating plainly

ProjectPoint creates project sites and keeps them indexed. It does not archive them, expire them, or decommission them when a project ends, and it has no sprawl reporting or permissions auditing across your tenant. If the problem you actually have is controlling the whole lifecycle of sites at scale, closing down the finished ones and policing who can see what, that is a different category of product with a different buyer, and those tools are usually complementary to this one rather than in competition with it. We would rather point you at them than pretend a provisioning engine is a governance platform.

Get in touch, and we will show you a register that still knows where everything is.

Book A FREE Discovery Call