[Liz Larsen]

Oof. That’s a simple question without a simple answer.

I have three pieces of feedback. Here’s the TL;DR:

1. Don’t think one explanation is enough.
2. Encourage your team to hold each other accountable.
3. Have a clear, well-thought-out procedure. Preferably, the procedure is written down and saved where everyone can easily find it.

Here’s the longer explanation, for those who don’t mind reading my ramblings.

1. Don’t think one explanation is enough. Learning Bluebeam is a journey. My direct supervisor has seen my “tips and tricks” presentation like 4 or 5 times now. She says she picks up something new every time, even though my presentations are virtually identical. We can only process so much data at once. And sometimes we need to experiment with the things we learned, go back, view the lesson again, and because of our newly gained experience we have the right mindset to add on top of it. So, schedule a lunch and learn or something similar, teach them the very basics of using the tools. Give them maybe a month to start implementing and to process, then do another lunch and learn where you briefly go over it again, but expand on the nuances.
2. Encourage your team to hold each other accountable. This one kinda sucks sometimes, not gonna lie. Liz long-winded anecdote time™: a few years back, when I worked at the firm who taught me Bluebeam. I started getting a little lax with one of our procedures. When we were collaborating on drawings with other people, everything went in Session. No exceptions. We did this to have that “single source of truth”, preventing questions about where information was stored. I received an email from an architect that had very clear instructions. To put the info in Session, I’d basically have to re-create what they already wrote. I figured it’d be quicker to just forward the email to my drafter with the direction to make sure he picked it up next time he was in session. He said, “No. I’ll only pick it up if I see it in Session.” At the time, it made me kinda angry. I thought he was being pedantic, which he was a little bit. But I also needed the reminder and I needed someone to help me follow-through with our standards.
3. I don’t need to expand on this one.

[Doug McLean]

I like the Lunch and Learn idea. I should schedule one of those.

One thing I’m going to do is go way back to the old TWI methods.of training where you show quick, show slower with some explanations, and then show again with more explanations and more whys. That method has worked for decades, yet we abandoned it.

I used it with our previous Estimator and she was fully up to speed in 6 weeks.

[Liz Larsen]

If you feed them, they will come.

[Vince]

When you are training create and distribute a set of folders so everyone can actually work through the training with you instead of just looking at what you are doing on the screen.

Use drawings from your company’s jobs that everyone will recognise.

Hopefully, then you will be able to create a few examples of how Revu has helped you measure, find discrepancies, extract info, etc.

This being able to relate what you are demonstrating to a recognisable real-life example will hopefully go a long way to help making things sink in for your attendees.

[Troy DeGroot]

All great responses so far, and I expected nothing less. I’ll add a few that came to mind while reading others.

1. Building on what @Vince said about using familiar documents. Make sure you recatch their attention once in a while by showing how you have solved a major pain point. This will get them interested and paying attention again.
2. I agree with @lizlarsen processes that are recorded and referenced often are going to be followed.
3. Create moments where students are teaching students. You’ll always learn more when you teach. Sometimes this means you have to curb your reflexes of wanting to reteach.
4. Let the faster students teach the slower students. This does a few things, it brings a new teacher’s perspective, it builds team buy-in, it establishes power users who others will go to with questions, and it also takes some weight off your back from carrying the success of it all.
5. Always be a listener, even the intern has good ideas!
6. Celebrate the smallest of wins. Not only project wins, but especially celebrate when a student teaches you something. That’s gold on both sides!

I can’t wait to read the rest of the comments.

[Isaac Harned]

#4 here is key, you have to develop your power users to the max, get your tech minded people excited about the possibilities. Look at your most repetitive and annoying workflows and get those as automated as your workflow allows. Once the tech minded see the time savings and consistency advantage, they will do most of the work spreading knowledge.

The hardest part will be the veteran adobe users, be patient with them as they try to completely shift the way they work in the program. Things like the markup bar for comments will be hard for them to find. Set up a standard User Profile right away with simple interface only showing the tools they need and distribute.

[Doug McLean]

One of the things I’m finding initially is to use the Tool chest tools, rather than the Tool BAR tools.
I set us specific tool chests for the various job descriptions, that are all colour coded, specific subject, and set layers… now its getting everyone to USE those instead of the generic ones that live on the tool bars.

[David Cutler]

You could try hiding the toolbar @Doug McLean – chances are they wouldn’t know how to find it if you did. 🤪

[Doug McLean]

🤣🤣🤣

[Roye Arie]

My add-on is try to establish the knowledge baseline, specially if you’re working with new people that you didn’t work with before, don’t assume they know or understand even things that appear trivial and basic (I know some Revu users that have ‘years of experience’, but if I talk to them about anything more than how to place a callout I get deer-in-headlight look from them).

It’s a great opportunity to educate people and elevate their comfort levels and experience in utilizing more from Revu, but it can be a delicate balance not to overwhelm them and make them shut-down to the idea.

Looking forward to hearing from you @Doug McLean on how things are going with the project.

[Doug McLean]

right now, its just in the beginning shop drawing stage.
We’re doing all the project startup stuff, finalizing schedule, finalizing scope… all that stuff.

Its going to be pretty wild when its all done.

[Doug McLean]

Yesterday, I walked the PM on this project through adding a Custom Tool chest to Revu.
Just a little something I created, very similar to the Architect Review tool chest that comes stock with Revu.
At the end of this, he says to me now you’ll have to show me how to use this because this is the first time I’ve seen this tool chest thing. 🤯😱
We have far too many people here using the tool bars, and not the tool chests when they’re doing their markups.

The Project Coordinator on the job LOVED the idea, and what options it will give her.

THIS is what I’m starting with.

[Roye Arie]

I’m not surprised man! There are plenty of people that are long time users that don’t know of many of the capabilities of setting/customizing toolsets.

It gives you both an advantage and a drawback. The advantage is that you get to coach them and open their eyes to more options, and the drawback is that it takes time, and if you work with multiple people on the team you may need to repeat some training several times until all are in a similar spot.

That’s awesome though. It’s a great feeling helping someone learn something new.

[Isaac Harned]

Heck yeah, just that little spark of, “Oh, THIS is the digital age”