Ah SharePoint, that cute little green icon in your Office 365 menu. Think of the endless possibilities to centralize all your business workflows and content in the cloud, and do not forget about those beautiful PowerBi dashboards monitoring your business in real-time.
The lure of SharePoint has attracted many executive teams to invest hundreds of thousands of dollars to migrate their business content to a web-based infrastructure. The reality is that most companies fail to implement even a tenth of what was envisioned.
So why is implementing SharePoint such a heavy lift for construction companies? The following are the top 3 reasons why SharePoint implementations fail in construction as well new strategies for achieving the desired end game for your company.
1. “We already have SharePoint”
Since the Microsoft stack is so prevalent in our day-to-day life it is easy to make the crucial mistake of dipping your technological toe into the SharePoint waters. Most IT departments defer to SharePoint for name recognition of Microsoft, and for the ability to earmark sizable budget dollars for a product with Microsoft’s backing (Microsoft isn’t going anywhere). There is an old adage, “no IT guy has ever been fired for choosing IBM”. The same applies to SharePoint.
Defaulting to SharePoint as a solution however is one out of convenience, not out of practicality. SharePoint’s capabilities seem endless, however most implementation seem to only get the “endless” part right!
The hard truth is that small to midsize construction companies rarely consider the resource requirements to conceptually design what they want to accomplish. Over time, ongoing management of the platform drains IT budgets. This leaves many SharePoint implementations half-baked and far short of the original intention.
2. No Code vs. Low Code
This sounds like a small distinction but can end up being the difference between a successful or failed implementation. True no code platforms allow the people who work with the day-to-day process to configure and setup process flow within a system. Low code systems mean someone you don’t know has to do this on your behalf and creates an interesting game of explain “HVAC Repair and facilities Maintenance” to the computer science kid.
Low code still requires coding, just less of it. This means you still need the development resource. Besides changing a background image and folder structure design, to do anything meaningful with SharePoint it requires the translation from high level concepts driven by departmental needs, to programmatic logic.
The Construction industry is notorious for changing conditions, and project variables. Trying to address these programmatically with an outsource contractor can mostly result in blown budgets. This is due to mis-engineered application development.
3. File vs. Data Content Management
The single biggest reason SharePoint fails in construction has nothing to do with development, cash, or design, but more to do with trying to marry the file-based storage structure to data reporting and analytics. When process workflow is driven by collaborative files, just like in SharePoint, there is no insight into the actual data within the file to monitor valuable metrics and data elements to populate dashboards. This real-time visibility is generally punted to post workflow completion and sourced from ERP data weeks later.
Thinking back to the origins of why companies want to move to SharePoint, the promise of centralized content and thus centralized reporting/dashboards is simply not a realistic endpoint inside a SharePoint file-based offering.
How Technology Investment in Construction Changed Over the Past Decade
15 years ago, the IT department was the gate keeper for technology. They governed when technology was purchased, but more importantly why technology was purchased. There was a three-year roadmap that was designed to put the company on sustainable and strategic path for process controls, reports, and content management. Since 2010, construction made a financial decision to outsource fulltime IT resources and move software decision making to the department level. Since we were moving to cloud based SaaS platforms, there is no need for someone to “manage the server” right?
Wrong. Not just kind of wrong, but really wrong!
By decentralizing technology buying strategies we created an industry term called “Appageddon”. Construction companies transitioned from “Roadmap with a gatekeeper” to “whack a mole” for any process fire. The lack of strategy created a disaster of data silos, non-integrated apps, a convoluted web of data synchronization, and let’s not get into what happens when companies onboard a new employee with 12 usernames and passwords….
The New Old School Construction Technology Strategy
We need to get back to basics as an industry and consider a few points…
- We Need to Centralize
without a technology roadmap we somehow tricked ourselves into thinking that App 1 +App 2+ App 10 = Efficiency and visibility. It does not, it just equals 10 apps, 10 data sources, 10 usernames and passwords, and 10 new reasons to call support. The whole application stack is not equal to the sum of it’s parts. - We need to create a strategy
from the executive dashboard down to data collection. Time to stop listening what the field guy thinks looks good up to management- Remember the promise of SharePoint and those beautiful, real-time dashboards. Dashboards are only as good as the data available to report on. If the data is stored across 10 apps, or sourced from 30-day old ERP data, what is the true value of the visualization? We must start rethinking the way we look at technology and stop thinking about “bells and whistles” and more about centralization and accessibility of data sets. This will help visualize our company’s activities in real time. - We need to quit evaluating software
from the end user perspective. Ten years ago “the field” did not have smart phones. We were just introducing this technology and many of the older field guys were just not competent enough in technology to utilize the devices. We made buying decisions purely based upon whether “Jimmy” could login and submit his fill in the blank. Now in 2020, the entire world had to figure out how to log into a zoom meeting or participate in a Teams call. We accelerated technology competency 10-fold overnight. (Plus, they’re on Facebook and sending text messages all day long, so they can figure out the daily report or timecard.) We must take advantage of this new discovered technology prowess and design workflows that are centrally accessible in one place and more importantly, design to “feed” data sets for our dashboards on a daily cadence.
Homework Assignment
Sit the executive team in a room and ask the following questions:
- On our best projects, what did we do well and what data indicators support this (Production units, scheduling, Change Order processes, etc.)?
- On our worst projects, what went wrong and what data indicators show the decline/issues. (Purchases, Change Orders, Punch Items, Delays)
- Create a spreadsheet that provisions for all the supporting data values to meet the reporting requirements.
- Design a DAILY (must be daily for rich reporting) report that gives the field a single form to report on these requirements.
- Design and define forms and workflows (work authorization forms, change orders, purchase request, equipment requests/transfers) that splinter off the report, but can provide collaborative workflows and process controls with referential data such as Contracts, Jobs, Vendors, and Employees for valid data capture.
