How an RC Car Taught Me to Be a Better CAD Manager
I know what you’re thinking. “What an odd and unlikely source of inspiration!” But hear me out. Times are changing. We see it at conferences such as Autodesk University every year. At first, many things seemed like far-off goals and dreams, but now we are working in a much more complex technological landscape. It’s much like driving around an RC car on rocky terrain.
According to Business Insider, the World Economic Forum released a report on how technology will transform the workplace. Of the top 10 “must-have” skills listed, complex problem-solving skills was number one. In fact, the report states that “36% of all jobs across all industries will require complex problem-solving abilities as a core skill by 2020.” (Curtin, 2018).
As CAD and BIM managers, we are faced with challenges of not only getting buy in, but also deploying all the shiny new technologies in the office, getting them all to work, maintaining them, and somehow constantly coming up with ways to improve and optimize them. It’s a moving target.
Years ago, in job interviews, I used to state with pride that I was very detail oriented. I stated that as a great strength. I now know that if you don’t also try to zoom out and look at the big picture every once in a while and how it all fits together, it’s much like having your head stuck in a fish bowl.
Traditional problem-solving skills are focused on analyzing a problem down to its detailed parts, trying to optimize those parts, and then putting those parts back together. One thing causes an effect to occur; it’s very linear. This kind of problem solving might work well for some problems and do result in the “quick wins” that many of us crave, but this alone just doesn’t quite cut it for me anymore as a CAD manager. I’m here to persuade you that it shouldn’t cut it for you anymore, either.
There are more complex problems out there in your workplace and beyond that require a different type of thinking to even begin to tackle them. What may appear one way on the surface might have many underlying things going on beneath the surface. How do you identify these kinds of problems? Well, a clue is when you try to apply traditional problem-solving skills to try to solve it. Did the problem come back? Did it not actually get solved? Did the “solution” actually cause the problem to get worse elsewhere in the long run? Bingo! These are more complex problems, and we would greatly benefit looking at them differently. So how do we do that? I’m here to tell you there are names for these much-needed skill sets, and one of them is called Systems Thinking (Aronson, 1996).
Now back to the RC car. How does this apply to Systems Thinking? Systems Thinking is about looking at the system as a whole and seeing how all the parts relate to each other, especially when you are trying to solve a problem or improve a situation. Forget linear for a moment. Think circular. Systems Thinking is more about synthesis of all the parts working together rather than analysis of parts in isolation. The links between the parts are so important.
I would say an RC car is an example of a system. Maybe not a complex one, but a system nonetheless. Completely disassembled, it really doesn’t accomplish much. But put together in the right way, it results in a vehicle that can maneuver around by means of a controller communicating direction via radio waves.
What if a wheel falls off? Will that affect performance on different terrain? If batteries are dead, the car can’t move. Are the batteries dead in the car or the remote controller? Or both? What if the batteries are working, but the wires aren’t connected right? Is it a remote controller issue or a car issue? If all of that is working, what if someone is also driving an RC car next to yours? Ever had someone else’s controller control your RC car by accident (or maybe a prank?) They were likely on the same frequency, so the one controller affected the other car.
This all illustrates at a small scale that there are components connected together for a purpose, and they interact with other systems, too. An initial problem might have deeper issues that resulted in unfavorable behaviors we see on the surface. Breaking apart one RC car does not result in multiple RC cars, so why would we continue to break apart all problems in such a way? Granted, there is a lot more complexity to the systems we interact with in our workplaces and beyond, but I wanted to give a basic example to get the wheels turning. Get it? J
Now back to CAD management. How can the modern CAD and BIM manager apply this type of thinking and problem solving in his/her workplace when it comes to getting the buy in needed to make improvements? Here are the methods and tools I use. Please note that the examples given might look unrelated at first glance, but they are all instances that could happen concurrently for me on any given day, and I have the challenge of prioritizing and coordinating them in such a way that they don’t affect each other adversely.
Look for Systems
The goal here is to document the inputs, process, and output of the current system you would like to potentially improve, so you know what you’re dealing with and can communicate it with others. When I want to document what a system looks like, I often book a conference room with a whiteboard so I can draw diagrams or jot down thoughts.
In my role, I follow the data from multiple departments to ensure it is translating and reflecting properly in manufacturer BIM content. This takes a lot of coordination and collaboration across teams to make it all happen. Along the way from subject matter experts of the product itself to BIM modeler subject matter experts, there could always be potential for disconnects, miscommunication, and more.
If there is a communication gap along the way, traditional problem-solving skills might not recognize that and simply point fingers at one of the most visible parts of the system, the modeler(s) of the BIM content. Those with crucial Systems Thinking skills know to dig a bit deeper.
One of the tools I use in documenting systemic issues is a Causal Loop Diagram. Figure 1 shows an attempt at diagramming the need for CAD and BIM standards.
The short-term solution of just making a quick fix for every project or request takes away time from building long-lasting standards. As CAD and BIM managers, we may know this to be true, but sometimes a visual can go a long way.
Figure 1
Drawing these types of diagrams takes some trial and error, but the main takeaway here is to show that there are circular links between ideas. If you would like to learn how to draw these diagrams, check out http://www.thesystemsthinker.com. There are also some great YouTube videos on it as well (https://www.youtube.com/watch?v=tTo06jbSZ4M). Back to this example, the numbered links go as follows.
- The explicit goal may be to have consistent deliverables. But we’re human, and sometimes things just aren’t consistent in our work, especially if we have no documented standards.
- If the CAD manager (or the person checking the work) just fixes inconsistencies, that increases the workload on those types of tasks.
- The CAD manager fixes the drawing, and the consistency of that one project improves and goes out the door that day, yay! Problem solved, right?
- However, this didn’t magically fix the problem. There is inconsistency in the system of getting completed drawings out to clients.
- Increased workload for the CAD manager on “quick fixes” increases time spent correcting inconsistencies over and over. Think “quick fixes” on new drawings, revisions, etc. With chaos, anything goes!
- Increased time spent correcting inconsistencies increases time not spent developing and maintaining documented standards.
- Increased time not spent on developing and maintaining documented standards increases time not spent on communicating and training on standards.
- Inconsistency in designer work across the board is still present (the problem never actually went away).
This might seem like an obvious example, but essentially what I am trying to illustrate is that a “quick fix” doesn’t really solve the initial problem. It just makes it look like a problem is “fixed” on the surface. This kind of diagram could be applied to properly maintaining and hosting BIM content, software licensing structures, analyzing ROI, and more. Yes, short-term and long-term solutions need to be considered together, but I use the diagram as a systemic problem identification tool in strategic planning.
Collaborate to Gather Insight
The goal here is to branch out and learn about an issue from multiple perspectives. This often means stepping “outside of your job description” and asking many questions to gather not only what is wrong, but what are the requirements to make it right. Sometimes this involves talking to just one or two people surrounding an issue. Other times it involves “campaigning” across multiple departments to get different takes on the matter if it affects many people. Be very careful that your potentially proposed “solution” doesn’t just shift the burden to someone else.
For example, I collaborate and coordinate software deployments with the IT department. Sometimes our software deployments don’t go well and it leaves people questioning why.
I once took it upon myself to learn how to deploy software through a program such as PDQ Deploy even though it was not “part of my job description.” In just 30 minutes of my time, I learned through a quick tutorial that often the IT personnel having to deploy software don’t get the right inputs and have to Google it. They also have to figure out coded information such as parameters and success codes as those things often aren’t provided either. Those things can vary per product and per vendor, so they have to Google it. They also have to figure out all the conditions to essentially make this thing drive on its own to install software, and if they don’t know those conditions, they have to Google it. See a theme here? (PDQ.com, 2015).
So, in 30 minutes of my time, I learned that the IT personnel having to write these software deployments have to get a lot of “guesses” right, and even then, something can go wrong. This presents a very differently painted picture compared to what is on the surface, doesn’t it? Using this information, I was able to gather insight from the IT personnel to help improve upon my part in a software deployment process.
One of the tools I use to help with capturing insight is mind maps. Figure 2 shows what one might look like if I were to gather insight on evaluating CAD versus BIM workflows to address a challenge of trying to move everyone to a new software platform. Granted, the actual mind maps I put together have a lot more detail and are strategic in nature, but this is what the basic structure looks like. There are many online tools to do mind maps. I happen to use a free online tool called Mindmeister.
Figure 2
By creating mind maps, I can then link everything together and get to a point where I can write requirements for improving a process. I strive to write requirements in specific language and in multiple forms (visual + written) to ensure the message is being communicated effectively. If we were to write/illustrate our requirements on paper and leave it on the floor in the hallway, will someone who isn't familiar be able to follow it?
Make a Proposal to Stakeholders
Putting it all together, I am then able to go to stakeholders with a proposed solution. The stakeholders are people who are highly interested in the success of something, so much so that it is their money and resources at stake, hence, stakeholder. Keeping this in mind, I now have multiple strong points to present:
- Visual and written communication of the problem (causal loop diagrams, etc.).
- Multiple perspectives on how a process could be improved or created (mind maps).
- Data in terms of time and money to implement (time/cost of proposed solution and implications of non-implementation).
Conclusion
To conclude, I hope these tools I have presented will result in stronger cases for improvement within your department that leave no stone left unturned. Increasing the chance for buy in across the teams will help increase your influence as a CAD and BIM manager and as a strategic process leader. What I have described here is just the start of a lot of other frameworks and theories on problem solving. I’m always learning and want to encourage you to keep learning, too. Complex problem-solving skills are needed for today’s CAD and BIM manager as we navigate the increasingly complex technological landscape in the AEC world in our little RC cars. Speaking of which, I need to sneak my son’s RC car back into his room as he was not aware that I borrowed it to write this article. J
Jisell Howe, CDT, has been in the construction and now MEP industry for nine years. She is currently the CAD Administrator for Uponor, a PEX pipe system manufacturing company in Apple Valley Minnesota. As an AutoCAD-certified professional, Jisell manages several BIM/CAD/PDM content databases as well as supports the multi-platform software needs for 50 people in the company’s Design Services department. She holds a Bachelor of Science degree in Applied Management as well as an Associate of Applied Science degree in Architectural Drafting & Estimating from Dunwoody College of Technology. Other educational interests include analysis of business systems, complexity management, and project management. She is a Top 10 Speaker at Midwest University and was most recently a speaker for Midwest University 2019 and Autodesk University 2018. Jisell has multiple articles published in AUGIWORLD magazine, with the most recent one in the October 2018 issue. She can be reached for questions and comments at jisell.howe@uponor.com.
Sources:
Aronson, Daniel (1996). Overview of Systems Thinking [Web log post]. Retrieved March 4, 2019 from http://www.thinking.net/Systems_Thinking/OverviewSTarticle.pdf
Curtin, M. (2018, January 04). 10 skills employers will want the most in 2020. Retrieved May 21, 2019, from https://www.businessinsider.com/10-skills-employers-will-want-the-most-in-2020-2018-1
Fine-Tuning Your Causal Loop Diagrams-Part I. (2015, November 24). Retrieved May 28, 2019, from https://thesystemsthinker.com/fine-tuning-your-causal-loop-diagrams-part-i/
Ideas Worth Spreading: How to Mind Map a TED Talk: Retrieved from https://www.mindmeister.com/blog/ideas-worth-spreading-mind-map-ted-talk/
PDQ.com. (2015, January 08). How to Build Your Own Deployment Package. Retrieved May 28, 2019, from https://www.youtube.com/watch?v=gbkBaOrTTKk
