Revit pilot questions

[ron.sanpedro]

We are getting ready to jump into our Revit Pilot Project, and I am looking for some insight from those who have gone before.

The project is a University assembly space. 20,000 SF, simple program of central assembly space with some auxiliary functional spaces on the edges. The project is urban infill, with a very tight site, and the front facade/relationship to street/relationship to adjacent buildings is the primary generator of external form. We usually work with simple forms with exposed materials. The design process is rigorous, and we fancy ourselves a boutique type firm. Thus we can be pretty fussy about SD graphics and such. We are also a 35 person firm, so we are right at the point of still trying to micromanage like a 10 person firm, while also already having the bureaucratic tendencies of a much larger firm. In other words, everyone has an opinion, and we spend a lot of time trying to listen to them all.

The team is primarily two people. The PA is an AutoCAD hater, but loves working with SketchUp. He is leery of new technology, but once something is proven to him he will run with it. The other person is our in-house hotdog user. He will try anything, and make the most of it.

The plan is to send both of them and myself (CAD Manager) to a 3 day intensive Revit Basics class. Then, over the 30 days following the class they will each spend 40 overhead hours, and I will spend 80, developing office standard content, using old projects to “mock up” the Revit process, and generally becoming familiar with the product. If the Revit Basics class doesn’t go into BuildingMaker enough, then I am also proposing that the same three, plus the two Design Principals, take a half day BuildingMaker class at least a few weeks before project kickoff, and spend some of those overhead hours developing our Revit SD process.

Lastly, the project is a University project, on a relatively tight budget, with some pressure to speed up the timeline, but of course the office wants the pilot project to still be profitable.

Any suggestions/comments/warnings would be greatly appreciated.

Gordon

[aaronrumple]

The plan is to send both of them and myself (CAD Manager) to a 3 day intensive Revit Basics class. Then, over the 30 days following the class they will each spend 40 overhead hours, and I will spend 80, developing office standard content, using old projects to “mock up” the Revit process, and generally becoming familiar with the product. If the Revit Basics class doesn’t go into BuildingMaker enough, then I am also proposing that the same three, plus the two Design Principals, take a half day BuildingMaker class at least a few weeks before project kickoff, and spend some of those overhead hours developing our Revit SD process.

Any suggestions/comments/warnings would be greatly appreciated.

GordonSounds like you have quite a cultural hill to get over.

Building Maker takes about 15 minutes to learn. And that includes a coffee break.

I wouldn't use Revit for SD. If I were just doing SD - I prefer Viz/Corel. The advantage of Revit is that the SD documents aren't dead end like SketchUp. The same design documents are your cd's. That's where you save the time.

[Mike Sealander]

I'm the "pop" part of a mom and pop office, and just started using Revit on 2 projects. I'd budget 30% of your time to Schematic Design instead of the more typical 15, and would also not try to develop office standards in a systematic way. Just wing it through the first project, pick up the pieces on the next one when you're familiar with wall and roof-ceiling types, etc. Make extensive use of AUGI and dealer support. My dealer in Boston has been great (MicroDesk) answering questions on the fly. As a former ACAD user and Cad manager at a firm like yours, I'll never draw a project in ACAD again. So good luck!

[kpaxton]

Gordon,

I have much to say about this and will be happy to share with you. Because of time constraints tonight, I will hold my peace until tomorrow, when I can share some really good insight with you - and some pitfalls that you may face and how to 'avoid' them. I'll also be happy to share these with you 'offline' if you wish.

Until then,
Kyle

home: kpaxton@cfl.rr.com

[ron.sanpedro]

Kyle,
comment away. I suspect I am not the only one just about to jump in the water.
Thanks,
Gordon

[ron.sanpedro]

I'd budget 30% of your time to Schematic Design instead of the more typical 15, and would also not try to develop office standards in a systematic way. Just wing it through the first project, pick up the pieces on the next one when you're familiar with wall and roof-ceiling types, etc.
My thought here is that the office refuses to let project budget go into learning, so I have budgeted overhead IT hours so we can figure out how our office can best use Revit, at least to a certain extent, and take that experience into the Pilot. Kind of a pre-Pilot if you will.
Also, I have the hardest time getting most people interested in new software, because most demo's and examples are not the kind of stuff we do. It is hard to convince a "design" office that software is good when the examples are not the same kind of projects. By building parts of some of our old projects, we can learn office specific Revit stuff, and produce things that by definition the rest of the office will pay attention to, and all without a hit on the project budget.

That is the idea anyway.

Best,
Gordon

[sbrown]

I have found offsite / off project learning to be have minimal impact. It is great for giving people an overview of the program and what it can do, but once they sit down to the project they forget everything. The new user knows it can do something, but can't remember how. So I strongly suggest that your training be set up using the project(doesn;t have to be billed to the project) but you use the real project as the training exercise. Take a small portion of the project and build it all the way thru. Make sure each student has time to recreate whatever you demo. So First day, import the cad site plan, set up your initial working views, talk about the project how it will work, who will do what. Will worksets be used? if so, start with them on, so the users sense how they are working(I used to hate to introduce these early, but recently have found, new users relate them to layers and "get" them fairly easily). Next layout your building walls, start with generic walls, explain the importance of the location line, dimension your building. set up grids etc. Then let the class go back and do the same. Next layout generic doors, windows, etc. Next generic floors, roofs, etc. After they are comfortable with the generic components, go back to walls, and show how to edit, swap out, etc. again reinforce the location line and what happens when wall types are modified based on the location line setting. Then move into detailing. Leave custom families until last(make sure one person on the team makes it their mission to become the best family creator in history). You should be able to work thru an entire set of CD documents for say a lobby and bathroom. If they can do that, then they will just move on into the project fairly comfortable. But if they've only "seen it" it will be tough.

Second tip ;NO EXIT STRATEGY!!!!! Do not let them operate under the assumption if the going gets tough we can allways dump out to autocad. If you let this happen it will set your company back light years before they will want to try again.

Third tip: Show them this forum, let them know their support mechanisms.

Fourth tip: discuss with your consultants, that you are using a new software and the exports may not be what they are used to getting from you. Work with the export features to understand what you can promise as backgrounds. Watch out for someone who wants the whole set in autocad at the end of the job(it won't be pretty).

Fifth Tip: HAVE FUN, remind the team, they got into architecture/ interior design, to build and design spaces, not draft. so when it takes longer to build a window then it would have to draft one, remind them of this.

[dbaldacchino]

Hi all,

I'm in a similar situation and I totally agree with the fact that off-site training, while it might make you feel all warm and fuzzy, is not very productive in the long run.

I started looking at Revit about 9 months ago and wanted to learn it. I found out that it's impossible to set a time line in man hours. Forget it. There's way too much and if you really want to learn it inside out, you have to dedicate weeks, months...and then there's the family editor. So I started checking out one of our office laptops and mess around with it, thinking about our current processes (or lack thereof!!) and figuring out how we would use it. As I found out how things work, my excitements and disappointments alternated, but ultimately, my excitements outweigh the disappointments. I started creating "content", but found that jumping in a project is the be the best way to really head forward. But it helps if you learn how to use schedules, modify and create tags, modify dimensions to suit your needs, creating some doors, windows, curtain walls, walls, roofs and your office titleblock.

So, after attending AU2005 (I promoted that as my main formal training and it was awesome, because I use the resources to date, especially the recorded sessions), I jumped into a 172,000SF Junior H.S., while also trying to figure out Revit Structure with an on-staff engineer. It's a lot of hard work, but I feel like I'm becoming an "expert", slowly but surely, especially with the help of these great forums and all that contribute.

One of the main mistakes I did was to actually suggest the exit strategy, although I'll fight passionately not to go that route. My main problem I'm facing is the "traditional" schedule, which DOES NOT WORK with Revit (or any BIM software for that matter), as you need more time up front, but a whole lot less in CD's. Please keep this in mind and explain it carefully. I have the PM, office manager etc. on my behind right now because I seem "slow". They don't understand that the not so detailed elevations I have right now are not dumb, pretty lines but an accurate rendition of what the building is today. And it keeps getting better as decisions are taken and modeled. I also need to learn to add linework in SD/DD on top of the views for speed instead of modeling everything, and you can get some work delivered to the PM and client a little faster. These can be replaced with modeled elements once the deadline is behind you.

If you have an excited person in the office who is not afraid to learn, is curious and passionate, he/she would be an awesome candidate to learn Revit. Let that contaminate/pollinate the rest of the office. As a start, I even set up another monitor facing away from my desk and cloned the display so people could see what working in Revit was all about. It was fun and a great discussion starter!

I found I'd rather work on a laptop than a desktop because i can take it home with me, post to AUGI (like right now!!) and test ideas when I please to. But that's just me :)

[cphubb]

Gorden,

This has been said in a few different ways, however it is really important so I will say it again.

The ultimate success using Revit is Dependant on successfully schematic design. You stated that your firm does not allow project budget for learning and we follow a similar mantra. However with BIM the design process is turned on its ear and if you do not allow enough budget hours in SD you risk failure. Our rough budget numbers have changed as follows:


Non-BIM SD 20% DD 20% CD 40$ BN 5% CA 15%
BIM SD 30%+ DD 30% CD 20% BN 5% CA 15%

The logic is as follows:

SD - define all spaces program code review and how pieces fit together. Begin to roughly
define materials and systems. Structure must be at at least SD and ideally DD 50% when leaving SD.
DD - Finish defining all systems, work walls doors windows fixtures etc and get all
dimensions worked out. Create all schedules. Second code review. Structural worked out now and doing calcs (Structure will need to work a little backward or you will flounder) Mechanical eq in place lighting and major electrical equipment worked out
CD - No more modeling. Create details from existing views. Note and dimension using DC lines and fills. Use the model as underlay for large scale details but try to use the
model wherever possible.


This is a simplified version of the best practices our firm is working on right now. PM me if you would like further help. We have had some trouble convincing clients and principals of the revised cost model. However the new AIA documents coming out shortly are supposed to address this.

Hope this helps

[dbaldacchino]

Chris,

Thanks for posting that info. One thing I'm struggling with is how many people should be allocated in each phase, or looking at the problem from another perspective, if you put a very small team in SD and DD on the project, what should the actual schedule look like? Does this mean we need to lengthen the timeline? This might not be an option, especially if we keep looking at projects the same way as we've done with traditional CAD. We need to find a new balance between manpower and time.

We've notoriously threw people/manpower at projects when the going gets tough, thinking it's going to solve the issue of "getting it done", and we know it hardly ever works. I doubt that when doing BIM, this will solve anything. I think it has the potential to create more problems, especially if there aren't many good users to choose from or you're still building up you're team's skills.

What has been your experience?

[Scott D Davis]

We are finding that we are using less people up front in SD and DD, and like everyone else, spending a larger percentage of the overall time up front in SD and DD. CD's have been shortened tremendously, and the overall project length through CD's is either the same or shorter at this point, which we attribute now to the learning curve. We expect that overall project schedules will get much shorter as Revit users get better and better.

Spending more time upfront in SD and DD has had another effect, which has been satisfied clients when moving into CD's. In a non-BIM environment, we seemed to be "designing" right up through CD's, when changes are the most costly (or sometimes even beyond CD's where the client would look at a project under construction and say "I didn't know THAT is was it was going to look like! Change it!) So spending time up front on design, and making sure the client is satisfied with the design, and they can VIZUALIZE it in 3D, has proved to be a tremendous time saver!

[cphubb]

Chris,

Thanks for posting that info. One thing I'm struggling with is how many people should be allocated in each phase, or looking at the problem from another perspective, if you put a very small team in SD and DD on the project, what should the actual schedule look like? Does this mean we need to lengthen the timeline? This might not be an option, especially if we keep looking at projects the same way as we've done with traditional CAD. We need to find a new balance between manpower and time.

We've notoriously threw people/manpower at projects when the going gets tough, thinking it's going to solve the issue of "getting it done", and we know it hardly ever works. I doubt that when doing BIM, this will solve anything. I think it has the potential to create more problems, especially if there aren't many good users to choose from or you're still building up you're team's skills.

What has been your experience?

David,

Since we are smaller 10 people we typically only use 2-3 people at a time on any one project and at least 1 of those is also working on another at the same time. It has been our (recent) experience that you should start with 1 person doing the actual work, working with the designer and or programmer, and add in 1-2 more near the end of SD. Those people should follow through with DD and CD, and dropping off near the end of CD as quality control begins you should be back down to 1 primary with a little help as required.

The BIG caveat here is worksets. We typically do not enable worksets on our small projects and only one person works at a time. However there are a few projects I almost enabled worksets in the middle of CD so we could do them faster. Large projects we typically setup worksets near the end of SD to continue along the most efficient path.

As far as overall time goes, I agree with Scott that we have now gotten the project the same or less than than we had previously, just a little backward. I also agree that our QC is improving as we realize the importance of doing a complete SD job and moving to DD with a good model. However some recent models were redrawn from scratch at the DD phase due to excessive meddling by designers etc. (you get the picture). We found the redraw to be quick and easy and the model ready for a good DD phase with few problems. Our goal is to get SD to the point where that does not need to happen, maybe next project.

[sbrown]

Depending on the type of work you do, you basically can skip DD. We are struggling to figure out how to redo contracts etc because what happens on jobs that never make it to CD's(lots of ours work that way) So you have a model at the end of DD that is going to make you a TON of money in CD's but the project stops/goes on hold etc. So your budgeting is very important. Until contracts are reworked, somehow you have to get your SD phase in line with your old way of working. to do this, I like to show the client "big picture stuff" in SD. Nice color fill plans, program/area schedules, lots of overall 3d perspectives and massing type views, vs the traditional plans and flat elevations. Maybe do one hand rendering to show character. This get the client to buy off on the big picture earlier and lets you move into DD quicker.

[dbaldacchino]

Same here...designing right into CD's is really the effect of seeing the building in 2 dimensions. Unless you are quite experienced and can visualize (I mean, really visualize without seeing!), you discover issues only when cutting a section through a space. A while back, we all noticed how many issued cropped up and problems unveiled when someone was doing a 3d walkthrough and building a model for presentation purposes only.

Chris, in our office I'm the only RB user right now and one engineer just started on RS. I'm going through a huge learning curve as fast as possible, and it's hard to gauge where you stand relative to where you'd be if you were not using Revit (I get asked this on a daily basis and it's hard to give an answer). SD and DD should logically be longer and more intense, but then CD's should be "a walk in the park" so to speak, as the decisions would have already been taken and the building fully developed.

I hope to get a better idea soon as to how schedules should work out, as it puts a lot of stress on new users that are expected to stick to traditional deadlines, and this is practically impossible as you're taking a radically different approach to production.

[jhs626]

Great content! There's a lot of sound advice in this thread. If your goal is to get your firm to adopt Revit, your approach will vary depending on who's pushing and who's resisting. Your biggest challenge, in my experience, is people.

Obvious to most of those reading; BIM technology is better than 2D CAD, it's more of an Architect's tool as opposed to an electronic pencil, and it will have a far greater impact on project teams, schedule, budget, design, etc. You just need to educate key people in your firm and turn them into advocates.

What's less obvious is how you approach adoption of Revit. I believe you're off to a good start asking questions and absorbing the advice below. Develop a strategy (not nec. on paper) based on your role, key people, and your firm.

You're strategy will vary depending on your role, whether you're the IT guy, a young Architect, or a principal. No matter which one... you a r e the de fecto champion of Revit. You can scare everyone away or peak their interest and generate positive momentum. If you're interested I could expand on this.

Getting key people behind the effort will involve politics, hard work, and education. I've piloted several projects over several years and it took a long time to get our firm's leadership to publicly stand behind Revit and use it on a big job. I believe that involving the firms leadership and getting their public support is essential. That's where education comes in.

Understanding your firm, it's culture, and their project delivery process is also important. You'll also need to be closely involved in any/all pilots to keep things positive. As momentum builds you'll need to recruit people to share the load. As that group develops it's important to be as transparent, supportive, and inclusive as possible... even when things get ugly.

Problems will arise, and you'll need to determine if their root is project-based or Revit-based. You can bet early on nearly everything will be Revit's fault, or so they want to believe. Your challenge is to be a fair and impartial judge.

This is by far one of the most important points; as a champion others will presume you are heavily biased and doubt your word. So, call a spade a spade and when Revit doesn't work... be the 1st to say it. Reverse the presumption and build a credibility.

Just so you know where I'm coming from: I'm a former designer (but not in Architecture) and I'm now a CAD Manager and I've def. had to build credibility.

There's a lot of great stuff in this thread, I hope this helps.

[dbaldacchino]

Very good points jh6262.

I'm lucky that management knows this is the direction we need to take and at least in our office, I know they trust me. Problem is they know how much I persevere, sometimes until I self-destruct :) So they're cautious at times to fully trust me! And I know that, but I think we're on the right track. At the moment I'm having a hard time feeling my way through this new process while pretty much working on the traditional schedule. I think the main problem is that PM's tend to not be as interested in the process of HOW we put a project together...they're too busy with other things (don't take this as a generalization). So if you don't understand what I go through to do something, it'll be hard for you to appreciate my pains. I'm sure I'm not alone here.

[jhs626]

Whenever I'm unsure of why somebody does, or doesn't, want to invest time in something I think of what's motivating that person or what they might fear. If your PM (or anybody on a project team) is not focused on HOW a package gets put together then somebody has to connect the dots.

I don't know what your PMs focus is on (let's say its budget, schedule, and coordination) but you can emphasize certain aspects of Revit that play into what motivates him/her or show how Revit can mitigate something they're concerned about.

Sometimes you need to be a subtle or invisible educator... so an even better approach is to get another Architect or team member to bring the message to the PM.

Another approach, perhaps the most important and clearly the most difficult, is to get your leadership to connect the dots... from their perspective - publicly. Most PMs want to please management and if management understands, and can articulate, the benefits it should be pretty easy to motivate the PMs.

As an IT person I think it's best to educate/enable people and allow them to carry the momentum, spread the word... bla bla bla. To that end... this is one of my fav quotes:

It is amazing what you can accomplish if you do not care who gets the credit.
Harry S. Truman

[mschroeder]

Very good points jh6262.

I'm lucky that management knows this is the direction we need to take and at least in our office, I know they trust me. Problem is they know how much I persevere, sometimes until I self-destruct :) So they're cautious at times to fully trust me! And I know that, but I think we're on the right track. At the moment I'm having a hard time feeling my way through this new process while pretty much working on the traditional schedule. I think the main problem is that PM's tend to not be as interested in the process of HOW we put a project together...they're too busy with other things (don't take this as a generalization). So if you don't understand what I go through to do something, it'll be hard for you to appreciate my pains. I'm sure I'm not alone here.

I don't have to tell you how difficult it is to fit a BIM process into the traditional one. I've been down that road, and it's a dead-end. You will be creating much more work for yourself and your team to "back fill" the deliverable with drawings and pretty pictures that have little meaning in a BIM centric approach. Even if you get though it, your management team and PM's won't have learned much from the process and will feel even more alienated by the technology.

Instead, bring PM's into your Revit users circle. Have them continually engaged in the development of the Revit model. They should know that what you see in Revit is a virtual model of decisions that have been made. Create 3D views that highlight decisions to be made (generic walls highlighted, or section box structural / architectural conflicts). Make sure they understand that this is a tool they have control over. Without this level of engagement you can expect many frustrated users who are trying to satisfy the PM's traditional expectations, and a PM who will communicate nothing positive.

my 2 cents.

[dbaldacchino]

Thanks Michael.

It's definately not easy. We're having more discussions about what kind of deliverables we need, what level of detail etc. One of the most recent discussions is "The Walk-Through". Some expect this as if you just click a few buttons and it'll be done. One has to realize that to make something look entirely finished, it pretty much has to! Unless you lie of course :) So on our side, we have to become savvy to "fill in" those voids where decisions have not yet been taken to make the whole process seem more seamless, and more "finished".

Once we go through a couple of projects, we should be in a better position, but when you're tailoring your templates, content etc. to your office while still managing a project (2 in this case....one's a re-site with some modifications, so I'm becoming an "expert" in design options and browser organization!), it's kinda difficult. jhs626's suggestions are sound. We've talked about the need to get everyone involved in learning what the process is to getting things done. Not just on the documents and design side, but even the PM side. You cannot appreciate the work of your team members if you don't understand what they do. I like the relationships that develop between members that talk to each other about what they do/are doing/go through on a daily basis and keep their team-mates involved all through construction even if the team is not officially a team anymore. There's better synergy and understanding. Those that don't, emit an aura of slavery almost....you know what I'm talking about: "Is that elevation ready?" or better yet, "Is MY elevation ready yet?" It boils down to culture, this needs to be hammered everyday by management. The little efforts by most of "the little people" in changiing the overall organization habits, turn out to be futile. Change needs to occur from the top.