SharePoint as a PMIS Platform for Utilities: What Works and What Doesn't

# SharePoint as a PMIS Platform for Utilities: What Works and What Doesn't

Most water and wastewater utilities are already paying for Microsoft 365. SharePoint Online is included in that subscription — which means the infrastructure for a fully functional PMIS may already exist in your technology environment. Whether you can use it effectively depends entirely on how it is configured and by whom.

This article provides an honest assessment of SharePoint as a utility PMIS platform: what it does well natively, where it requires expert configuration, and when a purpose-built SharePoint PMIS product is the right answer over a DIY build.

Why SharePoint Makes Sense for M365-Invested Utilities

The starting point for evaluating SharePoint as a PMIS is recognizing what utilities have already invested in. A utility operating on Microsoft 365 Business or Enterprise has:

• **SharePoint Online** for document storage and structured data lists
• **Power Automate** for workflow automation and approval routing
• **Power BI** for dashboards and reporting (with Pro licensing)
• **Microsoft Teams** for project communication integrated with SharePoint sites
• **OneDrive** for individual file management
• **Entra ID (Azure AD)** for identity management and role-based access control

This is not a marginal technology base. It is a platform that, when properly configured, can support robust project management workflows without introducing a separate vendor relationship, a separate data environment, or a separate per-user subscription.

For a utility where staff already lives in Outlook, Teams, and Excel, a SharePoint-based PMIS has a significant adoption advantage over external SaaS tools that require users to learn a new interface and log into a separate system.

What You Can Build With Native SharePoint

A well-configured SharePoint environment can support the following utility PMIS functions natively:

Document management. SharePoint's document libraries with version control, metadata tagging, and check-in/check-out functionality are well-suited to managing RFI documents, submittal packages, contract documents, and construction correspondence. Libraries can be organized by project phase, document type, and contract number. Version history is maintained automatically.

Structured data tracking. SharePoint Lists function as structured databases within a project site. An RFI list, a submittal register, a change order log, and a cost event tracker can all be built as SharePoint Lists with custom columns, calculated fields, and conditional formatting. These lists are accessible in the browser, in Teams, and in Excel, and they support multi-user editing with conflict detection.

Workflow automation. Power Automate (formerly Flow) connects to SharePoint to automate approval routing, email notifications, and status transitions. A change order approval workflow can route from field engineer to project manager to program director to finance — with every step logged, timestamped, and auditable. This is not simple to configure correctly, but the capability is genuinely there.

Dashboards and reporting. Power BI connects directly to SharePoint List data and can produce real-time dashboards showing portfolio cost status, RFI aging, change order totals, and pending submittals. A program-level dashboard that rolls up data across every active project site is achievable — with the right data model and Power BI configuration.

Site templates. SharePoint supports site provisioning templates, which means every new project can be spun up from a standardized template — same list schemas, same document library structure, same navigation, same permissions model. This consistency is what enables roll-up reporting and makes it possible to manage a portfolio of projects rather than a collection of individual, structurally different sites.

Access control. SharePoint's permissions model supports granular role-based access: project managers can edit, contractors can submit but not edit approved records, executives can view dashboards without touching underlying data. This level of control is built into the platform.

Where SharePoint Requires Expert Configuration

The gap between "SharePoint is included in your M365 subscription" and "SharePoint is functioning as a utility PMIS" is measured in hundreds of hours of expert configuration work. Here is where DIY SharePoint implementations consistently fall short:

Data model design. An RFI log in SharePoint is only as useful as the columns you define, the relationships you establish between items, and the validation rules that enforce data integrity. Without a proper utility-specific data model, you end up with lists that are structured like spreadsheets — which gives you nothing you could not get from an actual spreadsheet.

Cross-site roll-up. Each project in SharePoint typically lives in its own site. Aggregating data across sites — seeing all open RFIs across your entire capital program — requires specific technical approaches: hub sites, SPFx web parts, Power BI with multi-site data sources, or Microsoft Lists with the right column configuration. Getting this right requires SharePoint development expertise that most utility IT departments do not have.

Power Automate complexity. Simple notification workflows are accessible to non-developers. A full change order approval workflow — with conditional routing based on dollar thresholds, parallel approvals, escalation logic, and connection to a SharePoint list that updates automatically — is not. Power Automate errors in complex workflows are difficult to diagnose and can silently fail.

Governance and maintenance. SharePoint sites accumulate technical debt. Without governance rules for site creation, column naming, and list schema changes, a portfolio of project sites will drift into inconsistency within a year. When Microsoft releases platform updates — and they do, frequently — Power Automate flows can break, web part configurations can reset, and features can change behavior. Maintaining a DIY SharePoint PMIS is an ongoing IT commitment, not a one-time implementation.

User adoption engineering. A SharePoint PMIS that project managers do not use is not a PMIS — it is a ghost site. Adoption requires interface design that makes the right action the easy action, training tailored to the workflows, and a support model for when users get stuck.

DIY SharePoint vs. Purpose-Built SharePoint PMIS

The choice utilities face is not "SharePoint vs. SaaS" — it is "DIY SharePoint vs. a SharePoint PMIS built on your tenant by people who have done this before."

A purpose-built SharePoint PMIS solution provides:

• Pre-configured utility-specific data models for RFIs, submittals, change orders, cost events, and inspections
• Tested workflow templates for common utility approval processes
• Portfolio roll-up dashboards out of the box
• Standardized site templates that enforce consistency across every project
• Upgrade-safe architecture that survives Microsoft platform changes
• Implementation by consultants who have configured these systems for utility clients, not by internal IT staff learning on the job

The key advantage is that a purpose-built SharePoint PMIS is still running on your M365 tenant. Your data stays in your environment. You are not paying a per-user SaaS fee to a third party for every person who needs to view a project status report. Your IT department governs the environment. And your staff is working in a system that looks and behaves like the rest of your Microsoft tools.

Total Cost Comparison

For a utility with 50 M365 licenses managing a capital program of 10–15 active projects, a rough cost comparison:

DIY SharePoint build:

• Internal IT or SharePoint consultant time to build: 400–800 hours
• Ongoing maintenance: 100–200 hours per year
• Re-build cost when platform changes break the configuration: variable
• Hidden cost: the projects that ran badly while the DIY PMIS was being built

Purpose-built SharePoint PMIS:

• Implementation and configuration: fixed scope, faster deployment
• Annual support and maintenance: predictable
• Infrastructure cost: $0 additional (uses existing M365 subscription)
• Per-user cost: $0 additional for view-only access

Standalone SaaS PMIS:

• Per-user monthly licensing: multiplied across all project staff, contractors, and stakeholders
• Implementation and data migration: separate cost
• Integration with M365: separate cost or ongoing friction
• Data portability: dependent on vendor policy

For most utilities with existing M365 investments, the purpose-built SharePoint PMIS path delivers the best combination of utility-specific functionality, cost efficiency, and data control.

What Doesn't Work in SharePoint

To be direct: SharePoint is not the right tool if your utility needs:

• **Scheduling integration**: SharePoint does not manage construction schedules or critical path analysis. A separate scheduling tool (or integration with Microsoft Project) is required for schedule management.
• **Cost accounting integration**: SharePoint is not a financial system. Cost events tracked in SharePoint need to flow to your finance or ERP system through integration or manual entry.
• **Field mobile collection for large crews**: SharePoint's mobile experience is functional but not optimized for high-volume field data collection in low-connectivity environments.
• **Advanced earned value management**: If your program requires formal EVM calculations across a large portfolio, SharePoint alone is not sufficient.

These are not reasons to reject SharePoint as your PMIS core. They are reasons to understand what SharePoint does and does not do before committing to an implementation approach.

Practical Takeaways

• If your utility is licensed on Microsoft 365, you already own the infrastructure for a capable PMIS. The question is whether it has been configured correctly.
• DIY SharePoint PMIS implementations consistently underestimate the configuration complexity, the maintenance burden, and the expertise required to build a utility-grade data model.
• A purpose-built SharePoint PMIS provides utility-specific functionality on your existing infrastructure — without the per-user SaaS fees of a standalone platform.
• The most important technical capability to evaluate is cross-site portfolio roll-up. If you cannot see your entire capital program in one dashboard, your PMIS is not managing your program.
• Staff adoption is not a training problem — it is a design problem. A PMIS that is hard to use will not be used. Build that requirement into your evaluation.

The utilities that get the most from SharePoint as a PMIS platform are the ones that invested in the right configuration from the start — with people who understood both the technology and what a utility capital project actually requires.