Realities of Revit implementation (and why I won’t answer to ‘guru’)

I consult for several architectural and engineering firms, and on occasion I hear the team(s) refer to me as their Revit ‘guru’. While the intention is innocent enough, it always makes me cringe. Guru seems to suggest someone who has some mystical knowledge to ‘pass down’ to their followers, which leads to deliverance; success. While I agree that years of experience with the software does lead to a few ‘pearls of wisdom’ to share (see previous posts), I am adamant in my approach to Revit consulting – it’s about defining a unique approach towards a process, not about handing down a manual.

Here’s an important point to establish: an office shift to Revit is generally not about just choosing to use different software. It’s most likely a response to some other factor: a firm’s goals to become more efficient in project development workflow; a collaborative agreement with a multi-discipline design team to improve coordination along the design process; or the too often cited mandate: the client’s deliverable requirement.  I have seen each of these motivators have vastly different impact on how a firm responds to changes to their processes, and therefore a direct impact on how successful they are at making the shift.

I am a Revit Strategist. As such, I ask a lot of questions, gather information, challenge some perceptions, and synthesize the lot into a series of approaches that are then presented to a design team. There are ‘if, than’ discussions, and ‘why to do now, in order to get later’ posits, and a TON of ‘why was it done this way, and is that appropriate now?’ queries. It’s never easy to get an established workflow to change, and it’s key to impart to a team WHY they would benefit from change. It’s equally important for them understand some repercussions of resisting change, and it’s critical for them to see that it is their decision.

As the saying goes: If you are willing, you are able.
As this implies: If you (or your team, or your upper management) AREN’T willing…
…. you get the picture.

Willingness, let me be absolutely clear, goes beyond the team designers, and extends to the firm’s principals. Often, the challenges aren’t limited to design process, but also to manpower staffing approaches, capital equipment investment positions, all the way down to philosophies on imparting and cultivating knowledge across staff. All of these circumstantial factors affect how a firm can approach the transition. Some firms embrace the challenge, and see it as an investment towards one of those greater end goals. They understand their responsibility in committing to a strategic approach, which often involves trial and error, reevaluation and validation. That takes time, and as we all know, time equals money. We’re also painfully aware that money isn’t plentiful in this economy.

All of this takes communication. Establishing the firm’s goals – short- and long-term – in making the transition. Understanding the limitations. Defining the benefits, and discussing the repercussions. Identifying opportunities that go beyond the immediate task at hand.  Addressing the many factors that influence a team’s ability to adapt and succeed. Setting targets, gauging progress towards them, reevaluating the sustainability of the approach. Defining an exit plan, if needed. This is NOT a by-the-manual process. It is a strategic process, and no guru can simply make it happen.

My approach to consulting for Revit implementation is in stages:  I meet with the management team and lead discussion on identifying the motivation, defining the goals, and targeting metrics of evaluation.  I advise on selecting a flagship project to apply Revit, and assess the team’s existing skills to define a schedule for training and advanced project support. I then directly collaborate with the project team, providing baseline training and as-needed advanced level guidance and customized workflow processes in response to the design development.

The results have been rewarding. Users who have confidence in their skills, at levels appropriate to their tasks.  Teams who aren’t just good at building virtual models, but are actively engaged in the analytical process of building an efficient, data-integrated project deliverable.  Smart modelers.