ConvertedProblem Analysis

SharePoint Site Architecture: Dept vs Project vs Function Sites for Intuitive Navigation & Permissions

IT admins lack a decision framework for structuring SharePoint sites (departments, projects, functions, or hubs) that balances discoverability, save locations, and least-privilege permissions. Ad-hoc site proliferation creates siloed content, permission sprawl, and endless 'where do I save this?' tickets. A validated architecture pattern would cut support tickets by 50%, enforce governance, and make the intranet a daily tool.

Original Community Request

I really struggle to design my sharepoint sites in a way that makes sense to the end user so they can find stuff. I don't know whether to create sites for departments, projects or job functions or something else. Our users always moan they can't find stuff and they never know where to save. I also worry about having users see content they shouldn't see.

C

Community Member

28 March 2026

Problem Snapshot

Context
I really struggle to design my sharepoint sites in a way that makes sense to the end user so they can find stuff. I don't know whether to create sites for departments, projects or job functions or something else. Our users always moan they can't find stuff and they never know where to save. I also worry about having users see content they shouldn't see.
Success Proof
Site traffic starts appearing and at least one real sale is made.

Identified Pain Points

No decision matrix for site types (dept/team sites vs project sites vs function hubs)
Permission inheritance gaps forcing manual site-by-site access reviews
Missing hub-site navigation patterns to unify search and save locations across silos
Absence of lifecycle policies to archive inactive project sites and prevent sprawl
SharePoint Site Architecture: Dept vs Project vs Function | Collab365 Spaces