You Are Not A Victim

Executing a project in Revit can be a scary thing for a PM. To someone who isn't familiar with the software, it can seem like an inscrutable black box, full of chaotic magic and unintuitive processes.

It feels, I imagine, like a loss of control. The PM is on the outside, hoping against hope that the Revit users can pull off what needs to be done, and not having much ability to jump in there and fix things personally, or even evaluate if the team is on the right track. 

Many PM's check their egos and defer to the technical expertise of the Revit nerds. They ask questions about the capabilities of the software and seek advice for how to successfully deliver a project. This is good leadership, of course, the mark of an individual humble enough to know the limits of her knowledge and trust the team. 

There's a tricky balance to this, best explained by a strand of complaints I get from a lot of PM's and Principals from a number of companies:

"The users put way too much detail into the model. All our Revit projects blow their budgets in DD because everyone spends way too much time modeling to a level of detail that isn't appropriate!"

My answer: "Did you explicitly tell them how detailed you wanted the model?" It is the PM's job to communicate her intent to the team, and then to make sure they execute it. There is nothing about Revit that forces users to model in excessive detail too early (except maybe that it's kind of fun).

At the beginning of a phase, the PM should sit all the users down, explain how detailed the model should be, how detailed it should not be, make sure everyone gets it, and then check in frequently. This is normal stuff we've done for decades, Revit doesn't change the fact that the PM is the boss and sets the rules. We just added another spatial dimension.

Another complaint: "The users just get a new project and start modeling away. I don't see any sheets until two days before the deadline, and they look like crap! The users forget to look at the sheets until it's too late."

My response: "Why did you let them not print any sheets until two days before the deadline? Did you ask them to and they told you to bugger off?" 

There is nothing about Revit that prevents anyone from printing the full set from day one. In fact, that's my recommended best practice: plot a set immediately after model setup, and then every week thereafter. The sheets should never look bad. "Mostly empty" is okay if it's early, but "shitty" is not okay at any point in the life of a project.

I think the dynamic at work here is that the PM's lack of knowledge of how Revit works puts them in a reactive, rather than a proactive, stance. It's hard to shift between calling the shots and asking what the hell Revit uses if it doesn't have Layers. (Are Worksets just Layers? What do you mean sort of but not really??)

Revit might be a black box to you, but there is never a good reason for the sheets to look bad, or for the team to blow the budget fussing with details of the model that are going to change anyway. If your Revit users start giving you lip about 'that's just how the software works', they're not very good. Find (or train) better users. 

 

Zen and the Art of BIM Implementation

BIM is a completely new way of doing and thinking about what this industry has done for a long time. It's not a new plugin or a new way of doing some tertiary aspect of our work. It is a radical change to how we produce our core product. 

Some people act surprised, or offended, or disappointed, when an organization doesn't gracefully adopt BIM with zero pain, no fuss. Why? Unless the organization is entirely composed of perfect Zen Masters with minds like water, distress manifested as dysfunction is inevitable. 

Not one single organization has ever adopted some new thing without pain. Your organization will be no different. Accept this as calmly as you can, act and plan accordingly, and stop panicking. Take your lumps and keep moving. 

One step forward, two steps back

One of the promises with BIM, and tools like Revit, is that they will make your workflow faster and better with fancy features for calculations, coordination, and analysis.

It's easy to forget that it's also the tool we use to make the drawings, and we have to re-learn how to make good drawings when we switch to Revit. 

It is common for the BIM Evangelists to get really excited about the fancy stuff (and justifiably so; this fancy stuff is actually really neat) and not put much effort into making the drawings look good.

Often, the BIM Evangelists have figured out how to make the drawings look good personally but then quickly moved on, figured it was trivial.

Then the rest of the production staff gets into the Revit environment and they are quickly over their heads trying to do the fancy stuff and make good looking drawings, at the urging of the BIM Evangelists.

The result is shitty drawings and broken fancy stuff. Two steps back.

BIM Evangelists tend to be really smart people who struggle to understand people who aren't as sharp as they are with software. This lack of empathy means they are likely to lead the group into deep waters before the rest of the pack is ready. 

A successful BIM Implementation is all about timing. Walk before you run. Run before you fly.

Learn to fly before you jump off the cliff.

 

(A note: this applies to any firm where a significant number of people will have to work in the BIM authoring tool. If you only have one or a couple people who will be in the software, and they are all BIM savants, just stand back and keep them supplied with their caffeine delivery mechanism of choice.)

 

Concentrate Model Setups

Intensity beats extensity every time. 

This idea should be applied broadly, but here is a specific example: who sets up your Revit projects?

In the beginning of a firm's Revit adoption, it might be the case that a lot of people are simultaneously trying to grapple with learning Revit. It also might be the case that a lot of people in the office set up their own CAD projects. This might make you assume that a lot of people should learn how to set up Revit projects.

This is wrong.

In the beginning, you should designate an explicit group of people as the "Only These People Can Set Up Revit Projects" people, and that group should be as small as possible, probably 2. One moment, I'm going to write that again with a larger font.

The number of people setting up Revit projects should be as small as possible, ideally two.

The only reason I don't recommend that number be one is if that person leaves the company or gets hit by a bus, you'll be in a jam. So if the rate of new project setups is no more frequent than one per week, only two people should be setting up Revit projects. 

(Another good reason for there to be 2 people doing setups is to have an intellectual checks and balances, to make sure someone doesn't get a crazy idea and get too far with it.)

With only 2 people setting up Revit projects, they get good and fast at setups much faster than if they only set up a Revit project every six months.

With only 2 people setting up Revit projects, you don't have people making the same rookie mistakes on project setups over and over again that go on to plague the entire life of the project. 

At the beginning, intensively concentrate your project setup skills and experience in as few people as possible. These people will learn all the mistakes, and learn how to do it fast. 

Then, after many projects are under their belt, make them write down their process in detail. Now, anyone else in the company capable of following instructions and clicking buttons can set up a project properly. 

 

The Tribe and The Nod

When you experience and overcome suffering of a particular type, you tend to instantly bond with anyone else who has gone through similar suffering. Your shared experience creates an 'us', a tribe. 

I've think that the similarities of hard-knocks BIM education is greater than the differences between disciplines on typical design teams.

In the BIM Kickoff meeting, there is a 'BIM Team' and then there are all of the architects, structural engineers, MEP engineers, civil engineers, landscape architects, etc. 

The BIM veterans size everyone up and quickly assess who is in the BIM Team, and who is just an architect, engineer, or project manager. It typically just takes a nod and the right kind of eye contact. 

Someone says "Right, first things first, let's spend the next thirty to sixty minutes making sure everyone is crystal clear on the coordinates schema for this project, I've prepared this six-page instruction manual that we'll go over," immediately identifying that person as a BIM Team member. 

You catch two people do a small laugh and then the nod - they're on the BIM Team too. 

"What? That's easy. That shouldn't take longer than three minutes! Should just be by Shared Coordinates and then hit Acquire Coordinates."

Not sure who that guy is, but he's definitely not on the BIM Team. 

(By 'BIM Team', here I'm not talking about what someone's business card says. I'm talking about the BIM Team. The Tribe. The crew.)

This Tribe is multidisciplinary. It has members in the offices of each firm. Few people understand - or even know about - the existence of this ghost group of people who consider themselves an 'us.' It can be a huge aid to project cohesion when things start to go sideways. 

It's a small group of sharp people with arcane knowledge who tend to not care much about the inter-firm project politics because they have bigger fish to fry. They are responsible for the fundamental infrastructure of the entire project - if the BIM models fall apart, the whole project is out the window. 

Under that kind of pressure, and as the possessors of what is today still very rare knowledge - the inner mechanisms and procedures of pulling off vastly complicated virtual construction environments - the BIM Tribe identifies their own quickly, skips the politics, and gets after it. 

Why BIM People Bounce Around a Lot

"I don't know about this BIM guy. He looks good on paper, but he's been at 4 different companies in the last five years. Doesn't seem very loyal."

You've probably noticed this, or are this: a lot of BIM folks have bounced around a lot. It's not because BIM people are disloyal. It's because there aren't yet as many companies committed to BIM as there are individuals committed to BIM.

A lot of companies want to 'check out' this whole 'BIM thing'. They hire on a BIM expert, making words about how they're very excited to go full BIM, or whatever. 

Then the BIM guy shows up, starts implementing, and everyone immediately starts FREAKING THE FUCK OUT.

Because it's hard, and the organization wasn't committed - not really, not fully, not back-against-the-wall, there's-no-going-back-now, burn the ships, cross the Rubicon, alea iacta est committed.

They were actually trying to dip their toes in, the BIM guy said "come on in, water's fine!" and the water turned out to be a brine solution at 25F/-4C.

And so the first Revit project bails out to CAD to meet the deadline.

And the second. 

And then the PMs hate Revit because it destroyed their budgets, but mostly because they felt for the first time in a while like they weren't in control of their projects.

They didn't understand how to manage it, they don't know what LOD means, their eyes glossed over during the Model Progression Matrix marathon session, they don't understand why their ace CAD guy who went to Revit training for two days is now taking so long to lay out some simple pipe.

Loss of control is an enormous psychological slug in the face. (And this isn't an indictment against the PMs, to be clear - no one warned them, and their asses are on the line to deliver projects on budget.)

And then they ask the BIM guy to help out on this project that's gone to CAD, and his poor little soul is crushed because CAD is not what he wants to be doing with his life, so he bails to freelance or try to find a company that's actually serious about implementing BIM.

BIM folks have to take some responsibility for this. Too many of us are dew-eyed optimists. We drank the kool-aid. BIM is going to revolutionize the construction industry, cut 99.9% of RFIs, save money (for who?), the buildings are practically going to design themselves, it'll be grand.

But nothing ever is actually that great, is it? Sure, there are some case studies where it worked out like that, but that's because there was a dream team committed to a BIM success story. We're so busy hyping the pros of BIM, we sometimes forget to warn folks about the cons of BIM. People feel bait-and-switched.

I do not ever try to convince anyone that BIM is better than whatever they were doing before. I try to channel my inner grizzled, cynical, old-man-of-the-mountain grouch. I just ask if they are contractually on the hook for BIM deliverables, and then I offer to help them get through it with as little pain as possible. 

"Look, this is going to hurt quite a bit. Are you really ready for this?"

Change It Or Accept It

"If it can be changed, there's some action that will change it. If it can't, it must be considered part of the landscape to be integrated in strategy and tactics." – Paul Allen, Getting Things Done

Text boxes in Revit are terrible. People have been railing at Autodesk to make text boxes suck less for something like fifteen years. Maybe it's a hard problem to fix. I'm not a programmer, I don't know.

Since we couldn't change Revit's text boxes ourselves (not being programmers at Autodesk), we researched a work-around that other people on the internet had figured out.

We made a Generic Annotation family, put it on a Drafting View, make a Schedule that reads those Families, and use those Schedules for our cover sheet notes, sheet notes, and general notes -- all the places where Revit text boxes fail miserably.

The fake 'text boxes' format nicely. They're a little more complicated to learn than just typing in a text box, but it works fine and it looks good.

We don't spend time ranting about Revit's shitty text boxes anymore. It's just part of the landscape.

Life is too short to spend any time on things you have no power to change. Every time you come up against something that sucks, quickly ask if you can change it. If you can, do so. If you can't, accept it and adapt to it. 

 

He's Dead, Jim

We recently made the call in our Oakland office to officially give up CAD. We should have done it much sooner.

This is the new deal: we don't use CAD as the primary authoring tool for any new projects, period. If we get a project where the architect is doing it in CAD, we pull the backgrounds into Revit, do our work there, and export out to CAD to share with the design team. 

Here is a non-exhaustive list of the things we now don't have to do:

  • We don't have to maintain our CAD detail library.
  • We don't have to maintain our CAD symbol library.
  • We don't have to maintain our CAD linetype library.
  • We don't have to continually ensure that our CAD standards are aligned with our Revit standards.
  • We don't have to train people on CAD.
  • We don't have to waste time asking the question "should we do this project in CAD or in Revit?" The answer is always "Do it in Revit." It is a non-issue.

Here is an exhaustive list of new things we have to do because of this policy that we weren't already doing:

  •  

Ninety-five plus percent of all our work is Revit-required, and it has been for a year or two. So this isn't much of a shock to the office - almost nothing perceptibly changed, because almost everything is going to be in Revit anyway and we're all used to that.

That's why we should have done this sooner. We've spent too much of our journey dragging along the corpse of CAD purely out of habit.

The number one root cause of mangled Revit implementations is having the safety release valve of CAD. I see it over and over again. 

"Oh shit, the deadline came up really fast, we have to get this done NOW. Okay, just export the backgrounds and bang it out in CAD real quick."

"This project is small and fast, we don't have time for Revit, we'll just bang it out in CAD."

"Our Revit guy is busy on another project. Just bang it out in CAD."

When you always have an option that will save budget on this one project, you take it, because that's the smart business decision to make for this project. It's a safety release valve.

But you need a certain amount of pressure to learn. You have to be forced to become the hard-bitten Revit crew you need to be. You need to have your back against the wall. 

Bailing out to CAD is the smart business decision for an individual project, but it is disastrous for the organization over the long term. Instituting a simple policy of "No More CAD, no exceptions" takes off the cognitive burden of having to make the call on every single project.

I haven't heard of a single company for whom the switch to Revit was easy or comfortable. Don't think it will be for you - you are not a special snowflake. Grit your teeth and get it done.

 

What is the right ratio of CAD to Revit-required project load when you should pull the trigger and go full-Revit? I don't know.

We waited until we were cruising at 95+% and that was too late.

Maybe 50%? 

20%?

Fancy vs. Resilient

There are a few things that Revit can do that we don't use.  

One of the first things I learned how to do is to automate duct pressure calcs up to the AHU from the air terminal. I did it on a few small projects that I exclusively owned.  

We almost never do this in real projects even now. 

Why not? Because we decided that the cost and risk of maintaining that particular level of sophistication of our models was not worth it. 

We have many generalists, and a couple pros. The generalists, in general, aren't operating at the level of being able to maintain a model that smart and fragile. (It's not that they aren't bright enough to handle it, it's about the depth and breadth of proficiency they are asked to attain.)

The pros, typically, are too busy putting out fires and air dropping into crisis zones to build and maintain those smart fragile models either. 

We bias our workflow towards 'hard to break.' It's so easy to break one little duct fitting and bugger the whole calc, particularly on projects where you have dozens of users in the model.  

Will we do full air pressure calcs as a matter of course eventually? Almost certainly. (And we do use a number of smart/automated processes already.)

But we make sure we can nail the essentials as an organization, consistently, before we try to bolt on the whiz-bang stuff. 

Careful not to try sprinting before you have the whole walking thing down pat.  

(The danger, of course, is to get comfortable with the basics and then stagnate, get left behind, and fail to utilize powerful features. It's a tough balancing act.) 

 

Start Once

Firms new to Revit tend to continue to do early design phases in CAD, and then switch to Revit in DD. 

"Revit is too slow for quick concept stuff." 

"It's faster and saves budget to do it in CAD first." 

"We'll just import into Revit when we're ready to switch."

This is natural, but misguided. 

If you start in CAD, you have to set it up in CAD. 

Then when you switch, you will have to set it up in Revit. 

And then you will have to 'import' or trace all your CAD work in Revit (this is not a trivial task).   

Can your project budget absorb two setups? Do you like throwing away profit? Then ignore this.  

CAD is faster in concepts/SD when you are faster at CAD than you are at Revit, and have tight CAD templates and standards. 

Revit is faster in concepts/SD when you are faster at Revit than CAD, and have tight Revit templates and standards. 

Do you think in five years you will be doing many CAD projects? If not, you should get fast at Revit as soon as possible, and you should invest in tight Revit templates and standards as quickly as possible. 

Don't drag it out. Start once. 

 

 

(Also, there are some cool things that Revit and other BIM tools can do for you in concepts/early design that CAD can't. You won't learn about these if you aren't using Revit early.)

Training Programs Are Worse Than Worthless

This applies to "BIM People", not necessarily staff who just need to use BIM tools occasionally, or folks for whom BIM knowledge and skill is a complement to their core competencies. 

If you need a formal training program to learn Revit/Navis/Rhino/whatever, you probably aren't going to be a very good BIM person. 

If your staff needs a structured training program, you probably need different staff. 

BIM tools change rapidly.

BIM processes change rapidly (every other day we learn a better way to do things, or discover that the world is now ready to do it this way instead of that way).  

Things change so fast that no training program will keep up. As soon as you finish investing time in a training program, it'll be obsolete, and you'll have built a great "well this is just how we do things 'round here" infrastructure. Good luck with that.

If self-training/learning isn't embedded into your daily life or organizational structure, you'll get left behind. 

Build an intro to Revit/tool of your choice info packet, sure. But be careful. It might just be a device for catapulting people up to their level of incompetence, where they stagnate.

Maybe if they can't figure out the basics on their own, they won't be able to keep up with the change, so they should do something else. Something that doesn't change so fast.

This is a very sink or swim philosophy, and intolerant of all learning styles except self-directed auto-didacts. It is not very nice. 

How do you institutionalize this approach across a medium to large organization? Only hire auto-didacts.

Talk or Die

My girlfriend owns a 2000 Toyota Corolla named Sally. Sally spent the first half of her life on the East Coast, meaning that she is quite rusted and corroded due to road salt and water (two things that California lacks in any significant quantity).

Like many Toyotas, Sally has a slow oil leak.

Like many boyfriends, car maintenance is one of my contributions to the relationship. 

My strategy with the oil leak is to keep a five liter jug of oil in Sally's trunk and to top her off almost as frequently as we top her off with gas. If we go too long without filling up Sally's oil, she starts running pretty rough. If we let her go long enough without an oil fill-up, her engine will seize up and turn into a rock. We would have to spend a ton of money to get her running again.

BIM projects behave exactly the same way as Sally. The BIM project is Sally the car, and talking is the 5W-30 motor oil I keep pouring into Sally. You can start a project without any talking, but it's not going to get far, it's going to be rough from the get-go, and it'll soon turn into a disaster that will be massively expensive to fix.

The thing about BIM isn't so much that it's complex, although it is. It's that it isn't obvious. The consequence of this non-obvious complexity is that it is not a given how any thing should be done, because there are multiple legitimate ways of doing it. 

The best way to deal with this complexity of the BIM process is to talk. To talk early and to talk often. With as many people as you can. And by "talk" I mean "have conversations, ask questions, and listen", don't just yammer on about your pet process map*. 

Of course, at some point, you have to shut up and get some work done. Knowing how much talk is appropriate will only come with the experience of a few projects. Just keep this in mind: the consequence of talking too much is that you will annoy some people and waste some time. The consequence of talking too little is a massive pile of burning money, figuratively speaking. 

A pitfall that is easy to fall into is assuming that BIM is just the new, fancy, updated version of CAD. This is wrong. BIM is not CAD 2.0. BIM is not CAD except with a few extra features. 

BIM is a fundamentally different activity than what we've been doing, ever.

It requires different skill sets, mental models, processes, and language, and it is entirely different in scope. The rules that applied to CAD projects do not generally apply to BIM projects. CAD projects were relatively straightforward to set up, at least by the mid 2000's. There was a certain amount of communication required but in general everyone "got it".

No one "gets" BIM. We all have no idea what each other are doing. I have no way of knowing what coordinate system an architect is going to use, or if they're going use to use Worksets like Phases and Phases like Design Options. We need to discuss if we need to build the models to Facilities Maintenance standards or not. We need to talk about who is going to model the light fixtures, and when. And on and on. If we don't talk about these things, each team member is going to be running around in circles trying to figure out how the project is set up and how to simply get the model to a point that they can start getting actual work done.

This situation of needing to do a lot of talking at the beginning of every project is due to two reasons. First, like I said, BIM logistics are just really complex in a non-obvious way. Second, we're all pretty new to this. BIM is not a mature or stable technology yet, and we're all still figuring things out as we go along. 

I can certainly imagine that in another few years, the industry will mature to a point where most aspects of BIM project execution have settled out into standard workflows and methods that everyone is comfortable with, but we're not all there yet. Particularly for firms that are new to BIM, or are still developing their BIM proficiency, the communication imperative is the number one make-or-break factor in project execution.

In the next post I'll get into some of the specifics of actually how to effectively communicate on a BIM project, as well as identify the most important phase of a project. 



*Full disclosure, I'm a huge fan of process maps, and have an extensive archive of process maps I've created. Most of them are awful, which is why they're in my archive, but the process of mapping out the process is what was most valuable. Which is a bit meta.


How to Avoid the Number One Money-Burning Mistake Most Firms Make with Revit

There is a lot of talk, hype, and rhetoric about BIM. Technology evangelists and implementation specialists go into great depths about the capabilities, functionalities, and new workflows and processes of BIM. It's easy to lose perspective.

All the hype around BIM is the primary cause of the error that most new design MEP firms make - the same error that leads to massively blown budgets and a reputation-damaging dip in quality of drawing sets.

The perceived message from BIM evangelism comes in two flavors:

  1. BIM tools can do a lot of the stuff we used to do separately from our drawing efforts (like analysis and coordination work).
  2. BIM tools do the things they do automatically. 

These two messages make people think that what is being claimed about BIM tools is that pretty much all you have to do is model the "stuff", and the BIM tool will take care of the rest. 

Myth: All you have to do is create the model (the architectural model, or the piping model, or the duct model, et cetera) and then hit the "Make Drawings" button, and Revit will pump out your drawing set. 

Myth: All you have to do is create the model, and then hit the "Clash" button, and Revit/Navis/360 will make your model clash-free.

Myth: All you have to do is model the duct and pipe, hit the "size" button, and Revit will size the distribution system for you (and do ventilation calcs).

Myth: All you have to do is build the architectural model, and Revit will create an energy model for you.

Reality: There are a lot of buttons in Revit. I've been in Revit for five years and I'm still coming across buttons I've never seen and have no idea what they do. Every thing I've ever set out to do in Revit has taken somewhere between "a fair amount" and "an obscene amount" of time to figure out. Granted, I'm a slow learner, but the point is that nothing in Revit is automatic. Even the things that are automatic.

Producing good-looking drawings from the Revit model takes a lot of work, skill, and a deep knowledge of all the buttons related to making drawings. Few of the skills for making good CAD drawings translated to Revit drawings - it's a completely different learning curve. In fact, it's a widely accepted fact that the more you know about CAD, the harder it is to pick up Revit.

Doing coordination with a Revit + Navis workflow is in some ways riskier than when we were coordinating using CAD, because people tend to make incorrect assumptions about the level of development of a 3D model. In a design intent model, it's easy to look at a pipe and assume that you can move the ceiling up to it within an inch and call the model coordinated. But missing from that pipe was the flange size, valve body, and the unistrut pipe support - all elements that won't get modeled until later in the design/construction modeling process. Even when all parties are on the same page regarding the level of development, doing coordination takes a lot of work, a lot of phone calls, and a lot of meetings.

This isn't a Revit-bashing post. Can Revit make awesome looking drawings from a well coordinated model? Oh hell yeah. Can you size duct and pipe systems in Revit a lot faster than you can with a ductulator? Definitely. Can you use a Revit model as the basis for an energy model and save a lot of time doing manual takeoffs? For sure. 

But.

You have to be really good.

You have to know what you are doing.

You have to have spent a lot of time in the software. 

You don't just download a trial version of Revit and know how to crank out an awesome drawing set. You download a trial version of Revit, and then talk your boss into buying a license, and then you spend months and months in the software, and then you can crank out an awesome drawing set. 

It's like dieting, right? Everyone wants to be able to take a few pills and have a GQ body without changing anything else about their lifestyle. But the reality is that to get a GQ body you have to work really really hard for a long time and make drastic changes in your lifestyle.

It's the same deal with Revit skill. You have to earn it.

And that is the number one error that most firms new to BIM tools make. They don't invest in earning and learning the skills and experience required to kick ass at Revit. 

So how do you avoid this error and save your firm from burning a whole big pile of money? 

  1. Don't assume you'll be able to switch from quality CAD drawings to quality Revit drawings overnight. It's going to take some time. How much time it'll take depends on the next few points.
  2. Get expertise as fast as you can. Either
    1. Hire a BIM guru (a real BIM guru, not just someone who sat through a webinar once. Get examples of their work) who can get you set up. Or,
    2. If you can't or don't want to find someone who already knows BIM, support someone(s) in your office to teach themselves. And actually support them. Don't just tell Fred you want him to "pick up" Revit and keep feeding him 50hrs/week of CAD markups. It's not a bicycle, it's a major new software platform of an entirely different design paradigm that will produce your company's core product

If you opt for having someone in-house pick up Revit, here's how to do it:

  1. Win a Revit project. You can't learn Revit well without diving in to a real project.
  2. Assign someone to that project, and only that project, and tell them their number one priority is to figure out how to make good drawings using Revit.
  3. Hook them up with some training, but don't overdo it (and consider skipping training seminars). In most 2 or 3 day training seminars, you get overloaded with information and can only absorb about 15% of it. Intensive training is a bit of a waste of money. Instead: 
  4. Encourage your new Revit Guy or Gal to spend a lot of time on the forums, blogs, and video tutorial series. Buy them some Revit books (they'll make good monitor stands later). Send them to Autodesk University if you can afford it.
  5. Get them frequent feedback. Ideally, pay someone knowledgeable to do a QC of your Revit models and drawings - someone who can tell you specifically what you are doing wrong, not just "this bit here looks like crap". You're looking for feedback like "Copy monitor the grids and then hide them in VG > RVT Links > Arch > Annotation Categories, so you can adjust the grid bubbles per view. Also halftone them."
  6. Don't worry about making money on your first Revit project. You won't. Consider it an investment. If you can avoid a train wreck and deliver a decent set, you have just bought yourself access to all the Revit projects out there that were out of your reach before, and you can make money on those.

The big concepts here are that you learn by doing and you progress by getting frequent specific feedback. So jump in to a project, start pushing buttons, ask for help a lot, and get people to point out where you are going wrong often.