Software in the Middle

Last week we mentioned in a post, that software vendors are being placed in a weird spot by a split in our industry. The split is the one that exists between the individuals in the industry (keep in mind audience here is US based commercial/industrial) that create standards and the individuals that perform the day to day tasks of putting work in place. The division between these two groups is very large and there are few people that represent both camps. I can talk about this because I am in both camps (as are the other EpicBIM Contributors). That means that I do my best to contribute to our industries standards and also have an active role in implementing those same standards down to individual jobsites. I have been privileged enough to work with many individuals on both sides of this and I think that it makes me the right person to voice this issue. The issue is that these two groups that depend so heavily on each other are working in opposition. Not only are they working in opposition to each other but they actively believe the other side is doing things the wrong way. This is a situation that I find to be untenable. In this post I plan on pointing out the flaws of both sides. So let's get started:

I'll start with those that implement the work. If you implement the work you are out in the industry modeling, designing, managing construction, authoring documents, running coordination, and doing the day to day job of making sure that owners get the facilities they pay for. Everyone in this group has got a job to do and has only the tools and time to do it in that they are allowed by forces that are usually out of their control. Most of these individuals are not interested in the industry standards past what can immediately help them solve a problem. What this means to them is that if someone cannot put a standard in front of them with clear concise directions on what is required then they just don't have the time to consider it. And so the implementers mock the existing standards, ignore them whenever they can, and convince owners not to do them if they get the chance.  Don't tell me this doesn't happen. I have seen it in every area of the country by companies with every skillset. I understand the reason why this happens. All of the issues we deal with (interoperability, the other well defined standards, no budget, tight deadlines, etc.) do not allow any room for trying to implement standards that are not ready made for our individual work processes. So when you do take a look at the standards and they don't make sense and don't fit your workflows you call them "crap" and go about your business creating processes that work well enough for you or your company.

This is the wrong way. I have done this myself and I was wrong. It works on isolated projects but starts to fall apart as it expands. You end up spending all of your time solving the same issues for every project that do not really need to be recreated. Standards are needed to prevent us from starting every project over from scratch. There is so much that is similar on every project that can be standardized. But this will not happen if the people that implement the work don't start realizing that the isolated work flows they have made are just not that special (see previous EpicBIM Posts). They need to stop mocking the standards and start to get involved in them if they want the standards to actually help their work instead of hinder it.  I am amazed at the number of individuals I interface with that implement work that have nothing to do with the creation of standards. I would bet that less than 5% have input in the standards in any way shape or form. And yet the same people wonder why the standards do not fit the way we implement work. Stop complaining and get involved. Your input is needed.

Now for those that create standards. There are some individuals that create standards and put work in place. I am one of them. But the majority of people that I interface with in the standards committees I don't see in the work place. I don't see them at implementation workshops or in similar groups focused on implementation. They are not there. There are a lot of individuals from academics, from consulting, and from high level positions (read divorced from implementation) that are involved. And that is absolutely required to create industry standards. We need the support of all of these individuals to create good standards. But the lack of input from implementers has created a void. With good intentions those that create standards have worked hard to create ideas, venues, and organized data structures that could be very effective. And I think that what is out there is very close to being able to be integrated in everyone's everyday processes. But they need to be tweaked. They need to be edited a little bit because they do not fit current industry practice.

But the reaction from those that create the standards has not been a good one. When those that implement try to provide constructive criticism, the reaction has been to say "My process is right and it is everyone else that needs to change the way they implement in order to make it work".  Just look at some of the linkedin discussions from last weeks "COBie is Dead!" posts. The response was overwhelmingly from non-implementers with the underlying message that "you don't understand" and "you're just not doing it right". And that's a small example. I still hear the cries of "Down with Autodesk!" under the guise of Open-BIM. No wonder implementers don't take the standards seriously. A fair portion of the market place works exclusively in Autodesk based products. Here is the bottom line for anyone that wishes to influence the overall direction our industries standards need to take. You cannot malign the work methods and tools of the entire market place while at the same time offering your own solution that does not seem to fit their workflows. If you don't know, that is what you have been doing. That is how you are perceived. Find a better message. Figure out how to get people involved. Promote your message of being software agnostic without having raised hackles every time someone says the word "Revit".

And that leaves software. I see software as fitting into one of two categories. There are a bunch of software's that wish to distinguish themselves through the use of industry standards but they mostly fall into the same category as those that create standards. Their message is usually the "everyone else needs to change" (and buy my software) method. The rest of them are caught in the middle and end up looking like Phillip Morris supporting Anti-Smoking campaigns. They have standards that they are supposed to meet and support. And they want to. It is a good thing to say that your software works with the National Standard. But on the flip side there are the people that pay them money. And they want the software to function for their workflows (The ones they create in isolation). Then both sides attack them for not changing software to meet their way of doing things.

Does anyone see a solution here? I do. Implementers need to get involved in the standards instead of sitting around and complaining. Those that are already involved need to listen and adjust to make sure their systems can be implemented. And software will fall in line because they now will have a business reason for doing so. If you fall into either of the above two categories you should know that you are slowing things down. You should realize that your solutions are just not that special and start to contribute to the industry at large by following some of this posts advice. And now I would like to hear the thoughts from anyone who has something to say about this. Tell me if you agree. Tell me if I'm wrong. But most of all tell me your solution.

3 Comments

  1. Connor,
    Great post as usual and spot on! The solution is to get both parties involved and find a workflow that not only meets standards set forth but is also a functional platform for those in the field. I believe that the majority of those on the implementation side may see standards as some sort of "restrictions" on how they create their processes. However, I think if one creates standards, you can avoid the "reinventing of the wheel" for each project.
    I feel that the standards can help out greatly, yet it is something that needs buy-in from all parties involved in the project. Currently, we are working on a rather large project that is going to require a large amount of coordination, information management and compromise in order to meet the deliverables demanded by the client. The issue we face is that the standards or workflows for this type of deliverable doesn’t currently exist. Therefore, this causes our group to stand on both sides of this issue. What standards do we need to create in order to aide the implementation of BIM processes to facilitate the final product required by our contract? I think we are not unique in this question…..I believe multiple companies are facing this same dilemma.
    Our role is unique in that those in our group are actually wearing both of these hats – so this requires seeking out input and critiques on the process from others to validate the usefulness of standards – whether they be proposed or currently in use. This can be a double edged sword in the fact that it can be easy to get tunnel vision and go down a path that may be unfruitful.
    Regardless, this is going to be a very insightful investigation into exactly how BIM is being used on the project. Its quite possible my rambling here may have not offered an answer or solution to the issue at hand….however, I can concur that we are facing the same situation and are actively engaged in working through a solution. This post does remind me that diligence needs to be maintained in order to see both sides of this issue in order to find a common ground. The goal is to create standards and processes that are actually USEABLE for both parties. Both parties need to remain flexible as this is a fluid situation and therefore requires a willingness to compromise to meet the requirements set forth.
    I would love to hear from others who are currently going through this and to see what other pitfalls exist during the investigation, implementation and usage of standards.

    • Bob

      Hi Christian, DJ Phipps – great observations on the need for multiple views on standards development. How does this goal –

      ( The goal is to create standards and processes that are actually USEABLE for both parties. Both parties need to remain flexible as this is a fluid situation and therefore requires a willingness to compromise to meet the requirements set forth.)
      Actually get implemented during the NBIMS 3.0 process? Last year the NBIMS 2.0 Implementtion Team suggested that new standards be described with process tools (flow charts at a minimum, process maps and swimlanes as best case) so that fail points and pain points are explictly described. It is to be seen if this really works.

    • Bob,
      I am not fully following your suggestion. I think you are saying that process maps may help implementation. As Chair of the Standard Practices Subcommittee for NBIMS version 3 I must admit a bit of a split feeling on this.

      First I will say that Process Maps will be required. So be ready. But second I will say that I am not so sure that this is what will help get best practices implemented. I actually think the requirement of having a Guide for Use will be much more important. But beyond that the first step is to get individuals to the right information when they need it. It took me a while to even figure out how to get to NBIMS let alone find a best practice and apply it. A big part of NBIMS version 3 has to be about giving some attention to the way information is presented. It's my personal feeling that this will make a big difference.

Leave a reply