Most design and construction digital-delivery data solutions are just that; a single solution. However single solutions at the end of the project usually leave a mess of unintended consequences. As facility owners, for every single solution deliverable received, we are left with legacy systems that we have to try to incorporate into our other single solution legacy systems. Does it work?
As owners, over the years we have deployed numerous enterprise-document systems. Usually it begins with what the contractor gives us. As you can imagine, using and managing the data received from these systems has been a challenge. Since projects have a set time frame, the processes and tools that are used to manage them are considered disposable, and terminate with the project. The contractor moves and we are left with a pile of data. In the past it was hard copy documents. Notebooks full of RFIs (requests for information), plan rooms littered with sepias and drawings, attic stock looking for an attic. This contractor used Microsoft SharePoint for this project, another contractor, Meridian Prolog. In the past, if a contractor uses a particular system, we will bend our system (if we have one) to match theirs. Designers did the same, and now we have Newforma, OneNote, SharePoint, e-Builder, and a host of BIM (building information modeling) process tools—BIM360, BIM Anywhere, M-Six Veo, etc. You get the drift. In the end we’ll try to stuff the myriad pieces of data into a SQL database and hope that it’s usable later if we need it.
In my previous article I identified the owner analytics opportunities available using existing pools of data received and managed through these different systems. However, we are not anywhere near aggregating them into new useable pools yet. And yet we keep receiving new and different data from different Project Resource Planning Software.
In my book Architecture 3.0; The Disruptive Design Handbook, I list the challenges facing the profession and the practitioner, and suggest Design Solving Tools in order to Root Cause (yes it’s a verb) intractable problems so they can be placed on solving platforms rather than trying to be solved with single remedy solutions.
So as an owner, embarking on a new design and construction projects and wanting to collect that hard fought and paid for digital stuff, how does one specify a platform and not a solution?
Remind yourself the data is as important as the building. Actually, as we continue moving into a more networked and connected digital universe, the data will become more important than the building; because it can be aggregated with other data and create analytic pools. The physical structure will be easier to manipulate through data sets aggregated to weather, demographics and use, than just the old fashioned methods of manually adjusting the thermostat or turning on the lights. Look at the connected Nest Thermostat. Consider occupancy sensors that know who’s in the building. Imagine anticipatory technology that meters and adjusts the approach, greeting and way for finding your customers and stakeholders. At Kaiser Permanente we’re looking to reduce member parking requirements by creating a Lyft member who doesn’t need to park in our facilities. A smartphone app will bring a car to the member’s home or office at the right time in order to drive them to the front door in time for their appointment. This same app will monitor home care for this same member, providing facetiming or skyping assistance as necessary. Only data-rich connected buildings to members can achieve that.
So, as an owner, look to build a platform that can easily take advantage of existing social technologies, which will further enable diverse and large scale and ongoing collaboration. No, I’m not suggesting that you build a system on Facebook or Yammer (or am I?); instead think about all the stakeholders who will use the data and technology before, during, and after construction. Stakeholders trying to find their way through the facility will need facility floorplans as much as constructors. Therefore the platform shouldn’t be about identifying specific features; instead, it’s in identifying all of the types of the individuals who will use the data beyond the specific project solution.
Think of all of your stakeholders. Who will use the models? Are there challenges within your organization around understanding who will use the data? Don’t think of just your internal project management team. A building has many stakeholders during and after construction. Create a platform that’s both flexible and scalable.
In my book I describe Design Solving as root causing tool that is built off of W. Edwards Deming’s classic Plan-Do-Check-Act Learning feedback loop. The process is outlined as follows—define, research, ideate, prototype, choose, implement, and learn. Define and research is the plan. Ideate and prototype is the do. Choose and implement is the check, and learn is the act.
The Design Solving techniques are simple, especially when you continue to remind yourself that you are solving a Single problem, or even Multiple problems. Remember you’re building a scalable self-healing hackable platform that can host all kinds of solutions. That’s why I made the joke about Facebook earlier. Most Facebook users use Facebook in lieu of email. My daughter uses SnapChat in lieu of email. When we had solved a problem, which she was trying to solve through SnapChat screen shots, I asked her to email her correspondents with the solution she remembered that she didn’t have their email addresses. So she just SnapChatted the fixed screen shot.
Therefore meet with your stakeholders as far around and up the food chain as possible. Research and prototype a platform and invite your building team to help develop a platform and not a solution. Software will disappear and become the air we breathe without our awareness. If we create another SharePoint that won’t accept filenames because they have the wrong backslash then we’ve created the MySpace solution.
Cliff Moser is a director for Facility Planning and Design, National Facilities Services, at Kaiser Permanente. He is the author of Architecture 3.0: The Disruptive Design Practice Handbook. He can be reached at firstname.lastname@example.org