Does SharePoint Really Make Sense for Managing Your Construction Projects?

When a project is first conceived, it usually has a small group involved that shepherds it along until it warrants additional resources.  On many projects we are involved in it is not unusual for a year to pass until momentum builds and additional resources are needed.  It is during this phase of a project when project teams are most vulnerable from those pushing a SharePoint agenda.

When SharePoint isn't enough

If you are an Owner that is responsible for managing new construction projects and/or renovations of your existing facilities, then you surely recognize that there is a lot of information that has to be shared amongst the project team to ensure project success.  “Information” on a construction project is largely comprised of static documents and live data.  Static documents consist of Microsoft Word and Excel files, CAD files, scanned files, Adobe PDF files, Digital photos, etc., while live data consists of numbers or letters entered in via a keyboard that often show up in real-time reports such as Requests for Information, Change Orders, Daily observation logs, etc.

During the early phases of a project (prior to the formal design process), not much is going on.  Perhaps a handful of trusted sources have been hired to perform analysis?  The teams are small and their work product is largely in the form of static documents.  Discussions around these documents and all related communications about the project are easily managed via email, phone, and in-person meetings.  At this stage, someone on the team will suggest that all the documents be centralized in one location.  SharePoint is often the common response to this need.

The suggestion typically comes from 2 sources.

1. If driven from within the Owner’s organization, these recommendations are usually coming from the Information Technology departments.  They mean well but unfortunately don’t understand how the complexity of a construction project will eventually outpace the capabilities of SharePoint.
2. If driven from within the Program Manager that has been hired by the Owner then it becomes an opportunity for the program manager to charge for additional services while also putting themselves in a greater position of power as gatekeepers of the project information.

During the early phases of project development, the team is largely focused on ensuring that the project becomes a reality.  Unfortunately, not many are focused on the project controls aspect until it is too late.  So when the suggestion of SharePoint arises, it is often followed up with:

OWNER IT GROUP - “We have already invested in SharePoint for the department/company”

OWNER IT GROUP - “We already own the licenses and it will be inexpensive to setup and use for this project”

PROGRAM MANAGER – “We used SharePoint on the last project and we have a template that will accommodate this project.”

PROGRAM MANAGER – “We have a few proprietary items we built that will help us expedite our efforts on your project”

If the needs of the project in the early development phase didn’t change throughout the life of the project, SharePoint would actually work quite well.  However, unless the project is cancelled, the needs of the project always end up outpacing the capabilities of SharePoint.  Moreover, the number of external users begins to grow often introducing accessibility constraints since the SharePoint servers are often behind the Owner’s firewall.  While there are ways around these constraints, they are cumbersome and often frustrate the users who respond by going around the system.

Once the project has hit design, and certainly when it has reached construction, the requirements of managing scope, schedule, budget and all the associated risks grow dramatically. 

The team is now generating large amounts of documents and data.
Hundreds or thousands of requests for information are generating multiple potential change orders that in turn create individual Change Orders that need approval.
Pending budget and commitment changes are being generated on a regular basis.
Once the project becomes more complex, the Owner is advised to add additional project controls to properly contain the risks.  The Owner looks back at the last year and says, “look at all this information we have collected in SharePoint – can’t we leverage all this information?”  The individual that suggested SharePoint in the first place will naturally conclude that they can build additional capabilities into the SharePoint platform to accommodate the needs.  Agreeing to build these additional capabilities quickly turns into a slippery slope that can, and usually does, increase the cost and risk to the project.  Building a rock solid software product that is fully tested takes years.  Attempting to build these capabilities during an active construction project is a recipe for disaster.  Even more painful is the bad taste the Owner is left with after realizing they can’t easily maintain the system for reference after the project is turned over to their facilities group.