SharePoint project management system
Built for companies running real projects on a spreadsheet, a shared drive and a weekly meeting that exists only to find out what happened. You get a template project site, a task and milestone list with owners and dates, a risk and issue log, flows that chase the overdue work, and a portfolio view that rolls the whole thing up — on the Microsoft 365 licenses you already pay for. One written scope, one fixed price agreed before work starts, typical delivery in 2–4 weeks with 30 days of hypercare.
Representative dashboard — sample data
What you get
None of this is exotic. It is the same set of moving parts every project already has — a plan, a list of open problems, a set of deadlines, and someone chasing them — assembled once, in one place, so the answer to “where are we?” does not have to be reconstructed each week.
Every project gets its own workspace with the same lists, the same views and the same folders, created in minutes rather than assembled from whatever the last project manager copied. Consistency is the whole point: a person who has run one project can read any of them.
One list holding the work, with the statuses your business actually uses, a named owner on every line, and a due date that means something. Milestones are flagged rather than buried, so the dates the client or the board cares about are visible without reading the whole plan.
Risks and issues raised against the project rather than mentioned in a meeting and forgotten, each with an owner, an impact and a review date. The value is not the register itself; it is that an unreviewed item becomes visible instead of silently ageing.
A hub pulls the individual project sites into one place, so leadership sees open milestones, slipping dates and escalated issues across the portfolio without opening each site. What you see is trimmed to what you are allowed to see.
A scheduled flow reads the plan each morning and tells owners what is overdue, warns the project manager when a milestone is about to slip, and routes the sign-off that gates the next phase. The chasing stops being one person’s unpaid second job.
A client, a subcontractor or a partner reaches the one project they are on and nothing else, because each project is its own site with its own permissions rather than a folder inside a shared one. Designed as a model, not patched together from one-off shares.
How it works
A working session with whoever chairs the status meeting settles the phases a project moves through, the statuses a task can hold, the fields every project record must carry, who signs off what, and who outside the core team gets to see it. Written down before anything is built.
The template project site, the task and milestone list, the risk and issue log, the views each role opens, the reminder and escalation flows and the phase approvals are configured in your own tenant — then tested by running a real project through them rather than a demo one.
Projects that are currently running move in first, the old tracker is closed rather than left as a second source of truth, and the person who will own the system gets a walkthrough plus 30 days of hypercare while the new habits take hold.
One project on a spreadsheet is fine. It is legible, it is fast to change, and the person who made it knows what every colour means. The trouble starts at the point where there are several running at once, each on its own tab or its own file, each slightly different, and the only person who can answer a portfolio question is the one who maintains them. From there the failure is always the same shape: the tracker drifts out of date because updating it is a separate chore from doing the work, so the weekly meeting becomes the mechanism for finding out what happened, and the tracker becomes a record of that meeting rather than a live picture.
Moving this into SharePoint is not about tidiness either. It is about putting the plan next to the work — the documents, the Teams channel, the approvals — so that updating a task is the same motion as finishing it, and about making the state of the project something a machine can read. A spreadsheet cell cannot email an owner three days before a deadline. A list item can. That difference, repeated across every task in every live project, is most of the value here.
Everything below is standard SharePoint, Lists and Power Automate configuration in your own tenant. There is no custom code and no product to license on top, which is also what makes it maintainable by someone other than us after handover.
| Component | What it does | What it usually replaces |
|---|---|---|
| Template project site | Creates each new project with the same lists, views, permissions and document structure already in place | Copying last project’s folder and renaming it, then discovering halfway through that it was missing something |
| Task and milestone list | Holds the work with agreed statuses, a named owner, a due date and a milestone flag, filtered into the views each role needs | A spreadsheet tab per project, with conditional formatting nobody remembers the rules for |
| Risk and issue log | Records what could go wrong and what already has, each with an owner, an impact and a review date | Points raised verbally in the status meeting and captured only in the minutes |
| Decision and change record | Captures what was agreed, by whom and when, so a scope argument three months later has a written answer | An email thread somebody has to go and find, usually under time pressure |
| Project document library | Stores that project’s documents beside its plan, with the same access rules as the rest of the site | A shared-drive folder whose permissions were set once and never revisited |
| Reminder and escalation flows | Chase overdue tasks, warn on milestones about to slip, and notify the project manager rather than waiting for the meeting | One person manually reading the tracker and sending the same four emails every Monday |
| Phase approval route | Sends the gate decision to whoever has to make it, and writes the outcome and comments back to the project record | A verbal go-ahead nobody can produce later |
| Portfolio hub | Connects the project sites so status, milestones and escalations roll up into one place, trimmed to each viewer’s access | A summary tab somebody re-keys by hand before the leadership meeting |
This is the first real decision and it is worth ten minutes rather than a default. A SharePoint list is the flexible option: any fields you like, grouped and filtered views, and the thing that Power Automate and reporting read most easily. Planner is the option people enjoy using, because a Kanban board with assignments, due dates, checklists, labels and attachments is a pleasant way to run a week of work, and it sits inside Teams where the project already talks. Many builds use both — the list as the record of record, Planner as the day-to-day board for one workstream.
The part that catches people out is licensing. Planner’s premium plans — the ones with dependency-driven scheduling and a timeline — are not part of an ordinary Microsoft 365 seat. Microsoft is explicit that a Planner premium subscription is required for premium plan features (opens in new tab), sold as Planner Plan 1 or Planner and Project Plan 3. Nothing on this page assumes you have bought one, and we will say plainly during scoping if your requirement genuinely needs it rather than quietly designing around a licence you do not hold.
| Consideration | SharePoint list | Planner (basic plan) |
|---|---|---|
| Custom fields | Whatever the business needs — phase, workstream, client, billable, estimate, anything | A fixed card shape: assignment, dates, bucket, progress, priority, labels, checklist, attachments |
| Automation and reporting | The easiest surface for Power Automate to read and for a report to point at | Reachable, but the list is where a rollup across projects is simpler to build |
| Day-to-day feel | A grid. Efficient for the project manager, less inviting for everyone else | A Kanban board people move cards on, available as a tab in the Teams channel |
| Dependencies and a timeline | Not natively — dates are independent fields, so a slip does not reschedule anything downstream | Premium plan features, which need a separate Planner premium subscription |
| Licence assumption | Included in the SharePoint entitlement in standard Microsoft 365 business and enterprise plans | Basic plans come with a Microsoft 365 seat; premium plans do not |
Where the project data is relational rather than a flat task list — sub-projects, resources and allocations all referencing one another — the list may be the wrong data layer altogether, and that decision deserves its own look before anything is built. Our guide to Dataverse vs SharePoint Lists for Power Apps sets out the trade-off, including the licence consequence, which is the part that usually settles it.
Each project living in its own site is the right structure — Microsoft’s own information architecture guidance is that each unit of work should get its own site, connected by a hub (opens in new tab) rather than nested as subsites, precisely because projects start, end and reorganise. The hub is what stops that becoming twenty places to look: it gives the family of project sites a shared navigation, a single search scope and roll-up web parts that surface activity from the sites associated with it.
One property of that roll-up matters more than any other and is worth stating plainly: it is security trimmed. Content a viewer cannot open does not appear for them in the hub, which is what makes it safe to point a client or a subcontractor at the same hub as your own leadership. It also means the permissions conversation in step one is not administrative housekeeping — it is the thing that decides what the portfolio view shows each person.
Where leadership wants more than a roll-up — a genuine portfolio dashboard with RAG status, milestone timelines, budget against actual and trend over time — that is a Power BI report reading the same lists, and it is a separate piece of work with its own design conversation and its own licensing. This page does not sell it; our fixed-fee Power BI dashboard development engagement does, and the sensible sequence is to get the system capturing clean data first so the dashboard has something honest to read.
Two kinds of automation carry most of the weight, and neither is clever. The first is a scheduled cloud flow that runs on a recurrence you set in Power Automate (opens in new tab), reads the task list each morning, and tells each owner what of theirs is overdue or due this week — one message per person rather than a broadcast nobody reads. The second raises the exceptions upward: a milestone whose date has moved, an issue that has sat unreviewed past its date, a task with no owner at all.
The third is the gate. Phase sign-off uses Power Automate’s approval actions (opens in new tab), which handle sequential and parallel sign-off with reminders and timeouts, and the decision plus its comments are written back to the project record so the approval is part of the history rather than an email. The mechanics are ordinary; what the engagement adds is deciding which gates are real, who is allowed to clear them, and what happens when nobody does. Where approvals across the wider business are the actual problem rather than project gates specifically, that is the remit of our Power Automate consulting engagement instead.
One production note we insist on: the flows’ connections should belong to a service account rather than to whoever built them, so the chasing survives that person leaving. It is a five-minute decision at build time and an outage nine months later if it is skipped.
We would rather name these at scoping than have them found in month four. None of them is a reason not to build; each is a reason to design with the number in mind.
| Limit | What it means in practice | How the build handles it |
|---|---|---|
| 5,000-item list view threshold | A view that tries to return more than 5,000 items at once fails rather than loading slowly | Views are filtered and the filter columns indexed from day one, per Microsoft’s guidance on large lists and libraries (opens in new tab) — nobody opens “all tasks ever” anyway |
| One hub per site | A project site can belong to only one hub, so a project cannot sit in both a client hub and a division hub | The hub is chosen to match how the portfolio is actually reviewed; the other dimension becomes a field and a filtered view |
| Roll-up web part ceiling | The sites web part filters to “all sites in the hub” up to 99 sites, and hub navigation stops being readable long before its technical limit | Closed projects are archived out of the active hub rather than accumulating in it forever |
| No native critical path | Dates on a SharePoint list are independent fields; moving one does not reschedule what depends on it | Named honestly at scoping — if true dependency scheduling is a requirement, that is a licensed scheduling tool, not this build |
| Guest access is a tenant decision | A client or subcontractor reaching a project site needs external sharing to be permitted for that site | Agreed with whoever owns the tenant before the first external project starts, not discovered at go-live |
Permissions are the other thing that decides whether this holds together at year two. Microsoft’s reference on permission levels in SharePoint (opens in new tab) sets out how access flows from site to library to item and what each level actually grants. The rule we apply is groups rather than individuals, because a model built from one-off shares is easy to create and miserable to audit once there are forty project sites.
There is a real line here and we would rather draw it than argue past it. A category of project and portfolio management products exists, several of them built on the Microsoft stack, and for some companies buying one is the right call. The test is not company size; it is whether you need the capabilities below, because they are the ones a product supplies natively and a native build does not.
| If this describes you | The honest answer |
|---|---|
| A scheduler maintains a critical path with dependencies and re-baselines when a date moves | Buy a scheduling tool. Rebuilding dependency logic natively costs more than licensing it and will be worse |
| You level resources and forecast capacity across a shared pool of people and many projects | Buy. Resource management is the capability native SharePoint genuinely does not have |
| You track earned value, or timesheets feeding billing and cost-to-complete | Buy, or accept that this build would grow into a considerably larger engagement with clear eyes about it |
| You mainly need one place per project, visible ownership of tasks and milestones, risks that get reviewed, gates that get approved and a portfolio view | Build it here. This is the common case, and it runs on licences you already hold with no new vendor, no new login and no per-seat cost |
| You are not sure, and today’s system is a spreadsheet and a weekly meeting | Build this first. It stands up faster, and the field and status discipline it forces is the requirements document you would need before buying anything |
The usual fit is a company of roughly 20 to 500 people already on Microsoft 365 that runs a handful to a few dozen projects at a time — client engagements, implementations, construction or fit-out jobs, internal initiatives — where one person has become the human index of what is happening. The trigger is almost always specific: a deadline missed because nobody owned it, a client asking for a status report that took two days to assemble, a project manager leaving and taking the tracker’s logic with them, or a new hire who cannot tell which of four files is current.
Two adjacent cases are worth naming so nobody buys the wrong engagement. If the thing that needs fixing is a Power Apps, Power Automate or Dataverse build that already exists and has stalled or broken, that is a takeover of somebody else’s artifact rather than a new system, and our Power Platform project rescue services page is the one to read. And if what you actually want is a company intranet — news, policies, a front door for employees, document management across the whole organisation — that is a different design entirely and belongs to our SharePoint intranet and document management consulting engagement. This page is about running projects, not about publishing to the company.
It fits badly in two cases and we will say so at the consultation rather than after. If nobody will own the system, it decays exactly like the tracker it replaced, and the honest first move is to settle who owns it. And if the projects themselves are undefined — no agreed phases, no idea what “done” means for a task — then no system will fix that, and the working session in step one is where it has to be confronted rather than automated around. If your team is currently paying per user for a tool like Smartsheet to do this, the move off it has its own shape and is covered by our Smartsheet to Power Apps migration services.
Everything produced is yours from day one: the template site, the lists, the flows and the documentation live in your own Microsoft 365 tenant, never in ours. It is ordinary SharePoint and ordinary Power Automate, so your own team or any competent Microsoft partner can change it later without us. We do not publish fees on the site; how a fixed fee is set and what is agreed before work starts is spelled out on our fixed-fee process page, and if you want a sense of what drives the price of a SharePoint build more generally, our note on what a SharePoint intranet costs walks through the same scope drivers.
Related services
The wider build: information architecture, libraries, metadata and an intranet designed rather than accumulated.
Approval, reminder and escalation workflows across the business, not only the ones wrapped around a project plan.
The portfolio dashboard on top — RAG status, milestone timelines and budget against actual, built as its own engagement.
Further reading
Hand-written guides from our article library.
The data-layer decision to settle before the first list is created — relationships, delegation limits and the licence consequence.
How an approval flow is built, tested and escalated — the mechanics behind every phase gate on this page.
The symptoms that say a spreadsheet has stopped being the right container, written for reporting but true of trackers too.
FAQ
A site per project created from one template, a task and milestone list with agreed statuses, owners and dates, a risk and issue log, document storage scoped to that project, flows that chase overdue work and route the approvals that gate a phase, and a hub that pulls the portfolio into one view.
Usually not. Microsoft 365 seats already cover SharePoint lists, the Planner Kanban board and standard Power Automate. Premium plans in Planner need a separate Planner premium subscription, and are worth buying only for genuine dependency-driven scheduling. We check what you already hold before recommending anything extra.
Only if updating it is where the work happens rather than a second chore after the work. We put the task list in the Teams channel the project already lives in, keep required fields short, and let the flows do the chasing, so nobody types status into a system purely to feed a report.
Yes. Each project is its own site with its own permissions, so access is granted one project at a time rather than across the portfolio. Roll-ups on the hub are security trimmed, so someone who cannot open a project site does not see its items surface in a hub view either.
Comfortably more than most small and mid-size companies run at once. The two practical ceilings are a list view trying to return more than 5,000 items, which filtered and indexed views are designed around, and a portfolio past roughly a hundred project sites, where hub navigation stops being readable.
Typical delivery is two to four weeks from kickoff, with the date written into your scope. The template site, the lists, the flows and the documentation sit in your own Microsoft 365 tenant from day one, and 30 days of hypercare runs after handover while the habits set.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.