Tag Archives: Management

Don’t blame the software…

03 Friday May 2013

Posted by in Thoughts

≈ 1 Comment

Tags

, , , ,

Have you ever noticed that people tend to blame software for project problems? Or worse, for people problems?

I’ve been thinking about this for a while, and decided to post after I read Robert Green’s Cadalyst series on the “tool worship trap“. These articles describe how easy it can be to get caught up in the promises of new software (and yes, I’ve been there!), and the reality checks you need to be sure your expectations don’t get out of hand.

But this attitude has a flip side: fear of new technology. Or if not fear exactly, a transference of existing issues onto new software. I’m mostly thinking about Revit today, but there will probably be more examples in a future post.

  • “We’re over budget because we did this project in Revit.” (Are you sure it’s not because of all the client-driven changes?)
  • “Revit should have notified us that the slab openings moved.” (Maybe. But how would we have handled this in AutoCAD?)
  • “I thought coordination would be easier now.” (Well, it can be. But you still have to talk to each other.)

Basically, whenever I hear a complaint or an objection to a Revit-based process, I try to find out if it’s an issue now anyway, regardless of software, and whether it’s something that we could fix if we just talked to the person on the other end.

Revit’s not perfect. (Far from it…although it is getting better all the time.) But I don’t think it deserves all the blame it accumulates for problems that are either long-standing collaboration challenges — that could be just as true for two people working on a Word doc — or that can be traced to other project management issues.

Just some Friday musings…

Advertisements

Keeping up with standards

04 Monday Feb 2013

Posted by in Standards

≈ 2 Comments

Tags

, , ,

There’s an old joke in CAD Management circles that the wonderful thing about standards is that there are so many to choose from. (We laugh because it’s true.) For our firm, most of the time these are client-driven standards, which in turn are probably owner-driven. In these cases, we grumble, sigh, and then build templates to automate compliance as much as possible.

But what about internal standards? And, more specifically, what happens when they change?

I’m thinking about Revit families here — other kinds of standards will have to wait for another day.

To answer this problem, I went back to thinking about how we handled it in AutoCAD when a symbol changed or was added. Adding was easy. (“Here’s a new block.”) When we changed something, though, we had to think through how it would affect our projects in-progress. Was it worth updating them with the new block? (Maybe.) Was it worth updating our typical details? (Yes*.)

Taking this into Revit, I think the basics of the process are the same, but the challenge is multiplied due to the vast numbers of families and the various ways of accessing them.

But here’s how I think it can work:

  • If you need to update a family, go ahead and rename it. Don’t try to keep two versions hanging around. (At least not in the active folders. Backups are fine, of course.)
  • If needed, update your template so that new projects will use the new family. (This part’s kind of a no-brainer.)
  • Projects in-progress will continue to use the old family if it’s already been loaded. If you inadvertently load in the the new version, you should probably say “no” when asked, “Do you want to overwrite this family?”
  • If you need the new version in an existing project (and be honest, it’s probably why you updated the family in the first place), rename the existing family as zzOLD-family (or with your prefix/suffix of choice) and then load in the new family.

I’m in favor of the prefix method here because then all the zzOLD families will drop to the bottom of your project browser, where your users won’t be tempted to grab them when creating new instances. It’s also a pretty good visual clue if they do happen to select a superseded family.

Admittedly I haven’t put this into practice officially yet, but I think I’d like to. Am I missing anything?

(Back to the asterisk from above — updating typical details can be a huge chore. It needs to be done, though; otherwise you end up with old symbols perpetuating themselves through new projects. Maybe set aside a day a month for maintenance? I’ll have to think about that.)