You Know What They Say About ASSuming…
Special Guest Post by Melissa Thiessens
I don’t know about anyone else, but when I get asked for help at the office, it’s rarely someone stopping by and wanting to discuss the best way to do something for their project that goes out in 3 weeks. It’s usually them showing up in a panic, telling me they need to print that afternoon and that they have just spent the last 4 hours trying to get this family to work or these views to look just so…
In the early days I would get so caught up in solving the problem exactly as it was presented to me, building off of their sense of panic and jumping right into how to accomplish that specific thing as quickly as possible (while also often enjoying the challenge of pushing the tools to do something they weren’t necessarily designed to do.)
Eventually I started noticing that often after spending a good amount of time solving the original issue, we would find that it had affected something else in the model (usually rather negatively) prompting a new round of questions, which many times led to a re-thinking of the original game plan and a completely different solution.
After going through a few rounds of this with a newer employee, I came to the realization that I had been assuming that the job team had already approached the problem like I would: carefully considering a couple of options to solve their issue, exploring the possible outcomes of each one, and choosing the one they thought worked best in their case. I was further assuming that they had only come to me after spending some time on this solution and running into a roadblock near the end (I can almost hear you chuckling, but to be fair, this has actually happened once or twice).
Since then, when I get someone coming to me telling me that they are having trouble doing something in their model, before jumping in with both feet, I start asking them questions to help identify the desired end result.
- What is the purpose of this family or view? What information do they actually need to convey?
- What is the best way to actually convey that information?
- Who requested the information? Who will supply the information? Who needs to make use of the information?
- Where is the best place to display the information in the set? Where will it end up being used?
- When do they need it? When will it get updated? When will it be used?
Then I get to channel my inner toddler and ask WHY? Why is it a problem? Why are they trying to do that particular thing? Why do they think they need to do it (or show it) that way? Why did they decide to do it that way? Why are they using that symbol or family? Why don’t they just do this instead?
When I look around I see much the same thing happening all over in our industry. A problem is identified and there is a rush to get some sort of solution as quickly as possible without anyone taking the time to fully understand the reasons it is a problem in the first place, or what the actual need is.
Specifically focusing in on the realm of content – Manufacturers started hearing from architects and engineers that they wanted Revit content. Early on the assumption seemed to be that something that looked good in the drawing set like a cad block was all that was needed. Many manufacturers just imported the cad blocks they already had into Revit families, often just using 2D views with no 3D elements at all. Others actually modeled their products in Revit, but crafted families with every little detail (think 3D logos and bolts).
After actually trying to use the families in a project, people realized they wanted to be able to extract information about the product from these families. Here again the assumptions were different in each case. Some manufacturers added just basic name and size information while others added a giant list of custom parameters to describe absolutely everything about their product, from part numbers to color choices.
The fact that much of the current content out there was created based on assumptions, and not based on the needs of the actual consumers, means that it oftentimes does not end up getting used because it contains either too much or too little information for the end user.
We all know that wasting more time and effort is not what anyone needs, which is why I have been excited about the idea behind BCS since I first heard about it. It’s an effort to get participants from every stage of a project to start asking questions on a large scale across the industry to get to the heart of the actual issues and start to work on better solutions for everyone.
And while I know the only thing we can all agree on is the fact that we’ll never all agree on exactly what we need, it’s important to get these conversations started so that we can all move in the right direction. This is why I’m especially looking forward to the round table sessions at BCS this year. Check out the topics here; which are going to allow participants from all areas of the process to have a voice, as well as hopefully getting everyone thinking about all the other aspects of the problem.
While there will never be one “right” answer, unless people are willing to go looking anyway, we’ll all stay stuck with “just ok” and no one should last very long in this profession if that’s their attitude…
Hope to see you there!