[CONNECT] What are the advantages of project-based worksets?

I know this has been asked before, and I'm still trying to wrap my head around it. I'm not opposed to project-based worksets. I am, however going to have to find a good way to "sell" them to people who are going to complain "that's not how we did it before".

As far as I can tell, the biggest thing is the DGNWS Index. I'm still not convinced this is more than a nice way to keep track of files. Since our files are stored to the project directory as it is, we don't often need to go looking for anything. What other practical benefits does this have in the real world?

For everything else, we already have our project data in separate project directories. While it would be nice to have some of the resources there pathed automatically, everybody is used to just browsing to all of the project files. The workspace sets the client resources (and still would) and there aren't a ton of mission-critical resources (other than drawings and template libraries) the we would need regularly.

The other issue I'm concerned with is workset branding. While I can see the benefits of that on some levels, I see a lot of potential for confusion and problems.
Yes, when you try to open a file from one workset using another workset, you get the warning box. Point of confusion right there, as all of my users call me up and say "What's this?" Next point of confusion is when they select the wrong option and the project workset switches behind the scenes (as it should, but they might not expect) or worse, they switch the file branding to the incorrect workset. Not to mention that it's not uncommon to copy certain detail drawings and sheets between projects where this dialog would almost certainly become an issue. This may actually be a vote against project worksets...

I'm not convinced that we really need to use worksets, and I'm certainly not certain enough to convince my coworkers that this organizational sea-change is worth the extra overhead. Our other option is to have Client Workspaces, and then a single dummy client workset that does essentially nothing. That would miss out if there are some spectacular reasons to have separate worksets, but it would definitely preserve the status quo.

Do you have any particular success stories as to why the extra work of project worksets are a great option for your company?

Thank you.

Parents
  • Our other option is to have Client Workspaces, and then a single dummy client workset that does essentially nothing. That would miss out if there are some spectacular reasons to have separate worksets, but it would definitely preserve the status quo

    I would do that at a minimum as your DOT clients will be set up as different WorkSpaces.

    I can see where there is reluctance to set up one WorkSet per project. The move to ORD is going to difficult enough without throwing in this extra requirement.

    Again, your DOT clients are most likely set up to operate on the one WorkSet per project configuration. As Marc Thomas pointed out, the Sheet Index and ProjectWise are two reasons to go that route, here are some others:

    • Custom WorkSet properties as text fields - It is becoming a common practice to set up custom/advanced properties for the WorkSet and reference them as text fields in your sheet borders (and elsewhere). You can still use tags, text substitution, or what ever methods you had in V8i, but more and more DOT provided sheet templates have the custom property text fields baked in.

    • Project specific ORD template .itl files - Many organizations set up one, or more, template(s) per project. By setting up a seed .itl per WorkSet you don't have manually change .itl files when changing projects.

    Rod Wing
    Senior Systems Analyst

Reply
  • Our other option is to have Client Workspaces, and then a single dummy client workset that does essentially nothing. That would miss out if there are some spectacular reasons to have separate worksets, but it would definitely preserve the status quo

    I would do that at a minimum as your DOT clients will be set up as different WorkSpaces.

    I can see where there is reluctance to set up one WorkSet per project. The move to ORD is going to difficult enough without throwing in this extra requirement.

    Again, your DOT clients are most likely set up to operate on the one WorkSet per project configuration. As Marc Thomas pointed out, the Sheet Index and ProjectWise are two reasons to go that route, here are some others:

    • Custom WorkSet properties as text fields - It is becoming a common practice to set up custom/advanced properties for the WorkSet and reference them as text fields in your sheet borders (and elsewhere). You can still use tags, text substitution, or what ever methods you had in V8i, but more and more DOT provided sheet templates have the custom property text fields baked in.

    • Project specific ORD template .itl files - Many organizations set up one, or more, template(s) per project. By setting up a seed .itl per WorkSet you don't have manually change .itl files when changing projects.

    Rod Wing
    Senior Systems Analyst

Children
No Data