I’m in the process of assembling several procedural office standards for the 20ish firm I’m currently working for. This includes organizing project folder structure, establishing document naming conventions and developing standard cad library blocks, among other things. This firm has been around for many years and has managed thus far with little or no standards. In most situations, when there is a need, colleagues grab stuff from previous projects. Over time some pieces of this assignment have developed while others have been ignored. I’m hoping to not to start from scratch. My previous experiences, coupled with research are providing me with a good start. I am also incorporating any current office practices that could be considered the makings of a standard.
I’ve spent the past day or so compiling interoffice digital material, researching the web as well as compiling fragments from my former projects. I’ve found some good resources thus far. The AIA Best Practices section has been very helpful. The section on Project File Organization provided exceptional insight. Also, some of these threads and documents from websites have aided my task.
Essentially, the final drafts will need to be a collaborative effort. I plan on sitting down with co-workers over the next few days to get their insight and feedback. In the end, I will draw up a proposal and present the “package” to the firm principles. I’m hoping they will in turn offer their insight and critical feedback as the process moves forward.
Before I sit down with my colleagues, I’d like to do as much scouring and groundwork as possible. This inevitable leads me to the trusty archinect audience. I’d like to get some feedback from any readers that have had any experience in completing such a task. Specific areas I’m looking for insight into are:
1. Folder structure for your projects
2. Naming conventions – in the past, I’ve found it helpful to always try to include project numbers (at the beginning of the file name) in any document created (word, excel, dwg, etc). This allows for easy reference and retrieval down the road.
3. Any specific standards you find vital to the fluidity of your office operations.
A few additional notes:
I’m somewhat familiar with ISO, although I don’t think considering it for this office is feasible at this time. However, I am welcome to gleaning any bits and pieces of information if there are any worth the effort. The CAD library is something that will take a bit longer to develop and really a side project. The firm is considering incorporating Revit in the near future, so I do not want to spend a lot of time assembling blocks, etc. when Revit provides a lot of that internally. But with that said, I’m hoping some of my effort can spill over into this introduction and help guide the program towards an easily standardized tool. I see office standards certainly as a rigid and productive practice but good ones are able to easily incorporate new information into the fold.
I like to include the date in file names, 08252010 for example, just like the project number, it can help you locate something quickly. There are exceptions to this one though, Don't have a changing date in the name of files you plan to send out for others to use as an Xref. There is nothing worse than receiving a bunch of architectural details all with a certain date in the file name, and then 3 days later, getting new drawings with all new dates, you have to change every reference in every drawing instead of just copying over the old file!
As far as the general concept, I'm curious, who here works in an office that maintains strict office standards? Has it always been that way?
I've actually never seen strict standards. My office is much like how your's sounds, Ether. People pull a lot from previous jobs and adjust as needed. Unfortunately some crap details can get pulled along for the ride. Usually we are good at weeding them out, but it is funny how we end up correcting the same mistakes over and over.
For my office, I think the only way it could change is if the highest up person designed and implemented the standards, then they would follow the standards, since they came up with them, and they would be able to make others follow them. For me, If I come up with standards, no matter how good they are, I'd have trouble getting others to follow them, especially when things get busy.
I agree dates help in file naming structure in many situations. When I add dates to files, I put the two digit year,two digit month and two digit day, in that order. For example, August 25, 2010 is 100825. This way computers always put them in chronological order when organized by name (especially when spanning multiple years). This by the way is the type of conversations I've been having in my head the past couple of days (how and why sort of stuff). So when I propose these changes, I will hopefully have thought about it enough to answer questions and, well, sell it!
I think in most cases the situation depends on what the strict standards are. One thing that drives me crazy is to open an AutoCAD drawing and the original drawer only uses a handful of the "standard layers" supplied yet their is a whole range of colored lines within the drawing. The drawer simply changed one line "by color" and then copied or matched properties on the rest. Another example is importing blocks that do not have all of the elements on the 0 (zero) layer. Both examples can be a nightmare when trying to isolate specific layers or to making changes to the visibility of the drawing (think xrefs).
In a way, I think I posted this thread to also get some feedback on what are important standards? In other words, what should I spend most of my time developing and what should I spend the least developing? What will be a worthwhile standard to champion and establish? I am the "new" guy in the office but I do have the principles backing in this endeavor. They have wanted to do this for a long time but never put forth the effort. When I started working at this office, it was a nightmare for me to find things. Each project has a different naming convention and a different file structure. Everyone is aware of the faults but there has been no progress to fix the situation!
Thank you, ether, I also run my dates that way (and incorporate them into the beginnings of file names) and have always been frustrated to never find anyone else who agrees with that dating system. It takes a little bit of time to get used to but in the end it is a breeze and it helps keep everything so neat and organized... lovely. Just chiming in with my 2cents.
Yup, I know the feeling. I'm well aware of the benefits of having organization, It is just than in my experience, it goes out the window when people get busy.
Like I said before, don't adopt a naming convention that causes your basefile name to keep changing, I don't know how many times I get a file like Baseplan08202010.dwg from my architect and then baseplan08242010.dwg shows up a few days later and I've got to change all my xrefs. On a small job it is just irritating, on a big job, it is a huge waste of time.
"...I think I posted this thread to also get some feedback on what are important standards? In other words, what should I spend most of my time developing and what should I spend the least developing? "
I think time spent on the drawing standards should be monitored very carefully as you can spend a lot of time here and the practicality of enforcement may mean your efforts yield limited returns -- if some people are very set in their ways, if skill with CAD is uneven in the office resulting in the sets produced by different people being of very different nature and if the drawings are passed back and forth with consultants freely, enforcement can be impractical
the year convention you use I find to be the best --
year_Proj#_Author_Type of document (abbreviated)
with respect to where to spend time, are you also making recommendations for how the firm tracks/documents email correspondence? and what about CA documentation? meeting minutes? phone calls? RFI's? Change orders? Submittals?
I've found proper procedures for tracking these more useful and somewhat easier to get people on the same page about than drafting standards.
haha yeah cad standards have to be the toughest. In my office, we basically have two sets of drafting standards, one for each associate, if you are doing a job for Peter you better follow his standards, and of course David has own theories on how things should be done. For us it is mostly a source of comical tension rather than serious argument, but it can be a little annoying.
You bring up some very important points, jmanganelli. Yes, I believe this is the beginning of a way to standardize all of the documents coming in and out of the office. It will be a way for everyone to access the same information with the same working base knowledge. That's the benefit and goal of standardization, right?
CAD is only one facet of the application of standardization and one I'm certainly the most facile with. I'm aware of my idiosyncrasies about the program and can complete tasks while respecting my colleague's idiosyncrasies about it as well. But when I need to retrieve information from a drawing on a project completed several months ago (or years!), it's next to impossible to do it without help. If the folks who worked on these projects were not around to offer guidance, the firm would be in big trouble.
I think, by examining the file naming conventions of AutoCAD for example, or even viewed more broadly how we utilize it as a tool in the office, this can be applied in similar ways to other facets of the standardization process.
Also, I agree with monitoring my time closely but if implemented correctly, standardization can in the long run save offices (more) time and money!
Does anyone mind sharing a working folder structure they feel works well? I hope to have my working version posted in the next day or two.
Ether, I am highly suspicious if we work in the same office, except the timing of some details are off - our stories coincide too well :)
Our office has grown rather tremendously this last year *knock on wood*, and what with all of the new people, our principals decided to look at standardizing. They approached it by creating a "Best Practices" group of 4-5 employees (new and old), charged with sorting out and coming up with standards.
So far it's been a mixed bag. The group has come up with good ideas, and have proposed them to the principals. Right now the largest challenge is not coming up with standards, but actually getting a final go ahead. I don't know if it's really low on their radar (which is potentially understandable, they are after all running a business), or if they are fearful of change/implementation, or what. But it's been a "hurry up and wait" situation, and without any momentum the group has turned stale. Be warned of that battle. Or be very proactive with the principals, assuming your level/relationship allows that.
We also name/date our files as you do, year/mo/day, for the same reason (sorting). We've spent time on our project file organization, and generally, after reviewing some of those from people's previous firms, chose to go the "less is more" route. We've seen some folder trees that go on forever, and while being all-inclusive, at the end of many projects you end up with many empty folders. What's worse are the "grey" documents, that could be filed in multiple folders - thus causing the user to waste time going through empty folders until he finds the right one his workmate thought it should go in.
Instead, we've created a core number of folders, and if the situation arises the PM can of course create the one-offs.
"Everyone is aware of the faults but there has been no progress to fix the situation!
Same in our case. I propose the following reasons: the old guys have learned where everything is in quirky place, so they have no need to change at that point. Secondly, with smaller firms, I've noticed principals/owners get antsy if the time your spending is not billable.
On a related note, in my experience as a firm hits the 20+ mark it really reaches a critical mass where standards need to begin to be looked at and introduced.
While standards are/can be rigid, and can be thought to potentially go against the free-flowing movement of design, one of our guys came up with what I thought was the right approach: "Let's just get to the point where we can focus on architecture." Ie, people shouldn't have to spending their time looking for the office graphic standards, or doc templates, or what colors the office uses, or cad blocks...they should know where all of their "tools" are, so that they can concentrate on actually designing/problem-solving.
Another perspective one of our principals wanted us to understand: standards are not the end-all-be-all. If the situation warrants doing something new/if following the standard doesn't look right/fit the situation, then he wasn't going to hold it against us. He'd much rather have us think about our drawings rather than following rote standards, regardless.
I touched on some of the priorities you should focus on. Even though we also are switching to Revit, it's not going to be the whole office over night - just one project at a time. I imagine the route we're going to take - what with the existing CAD projects - that it will take at least a year to get the whole office on to Revit. Therefore, I think it would still make sense to standardize your CAD for that period of time. At least have something written down, so that when you switch over to Revit a template of the ideas touched upon is already in place.
Secondly, while architects produce drawings, the amount of time spent on project management runs a close second. Make sure your office knows which documents to use for what occasion and where they are kept on the server. There's nothing worse than someone looking for an affidavit to re-use in an old project, or the company designed punch-list, or RFI/Submittal/ASI logs. Searching for documents (for anything) is such a time sink. That's what your fighting.
That's pretty much it. I would like to go off-topic a bit and discuss the office library. In my experience it is never either a) organized or b) that organization is relayed to the rest of the office. I also think it goes back to the "billable" time issue - as in, they pay you to work, not to research, learn, and read. Complete opinion there, of course. But I've just never felt welcome to check out what's in there (around the office). It always seemed that if you have time to check it out, you have time to draft/manage. Anyways - if the Internet isn't enough deterrent (people researching there), then make sure everyone in your office knows what's in the library (both materials and books/references).
after working in four firms, the folder structure i found most useful was one folder for all base plans -- each one named PROJ#_BASEPLAN_ARCH or PROJ#_BASEPLAN_CIV (or better, PROJ#_BP_ARCH, PROJ#_BP_CIV to save on characters) --- then the onus is on individuals to make sure there is only one baseplan at a time, not several with different dates, (though to some extent this is inevitable)
the file structure is something like proj#/folder#/task#/disc#
for instance something like this:
010034/100/101/03 means the project is the 34th project in 2010, i am looking in 100 series folder which is admin, I am looking in the administrative file, "correspondence," and I am looking in the structural discipline folder 03 which means correspondence was with the structural engineer
This is actually in my domain of expertise for once!
As for numbering, I agree with the general sentiment.
However-- and this is a big however-- your file naming system should not only be an organizational tool but an also an indexing tool.
And unless you use something like the ISO system where the concept is generally universal, inventing your own system generally leads to disaster unless this is someone's full-time job.
When it comes to the filing part -- which all firms should keep paper copies as your data as a tangible legal liability-- many of these file naming conventions do not translate over very well.
In electronic databasing, individual files within a larger organization typically have a key... meaning that all other aspects of the identifying information can be optional. The key is what makes it unique and also be able to have more than one name.
The key is what can make this both a filing system and an index system.
Residential. 34th Project. Exterior. Direct Client. Client: Ryan Jameson -- March 04, 2010 -- Elevation, Design Document by Michelle Johnson: Preliminary-- Not Approved.
This primarily works because the only thing that matters is the R0034 part.
What if it doesn't have a date, an author, what if data is missing? What if certain aspects of the project can't be quantified?
It also works in filling better because it allows you to file by project type, then sequential order of project (F.I.F.O-- First in, First out!), then by client name and then by date.
Yes, you could do it with access or you could even write your own SQL database.
You could even file it manually.
The thing I dislike about arbitrary filing systems like ISO is that there maybe actual logic behind it... but it isn't "object" oriented so to speak.
Organization of libraries is pretty similar to ISO except that in addition to a numerical organization, the various numerical organizations are broken down into topics. So, even if the system isn't being categorized purely by number, the system is organized by type followed by the number categorization.
In that sense-- unless what I know what the corresponding numbers are-- I'm going to be looking for object or object types to locate a file.
The other problem with filling by date is what happens when you have 3 concurrent projects for the same client? Would you know the exact dates of each individual project?
What if you want to cross reference all direct client (one-on-one) healthcare projects done by Michelle Johnson?
If you can at least keep a spreadsheet (doesn't even have to be a database), you can track information much better.
Unicorn, when you send a drawing with that file naming system to a consultant for them to use as an Xref, how do they respond?
I find it really irritating to have to decode someone's intricate naming system, no matter how logical it is. I want a name that is relatively short and to the point, this is very cumbersome.
Like others noted, I guess it has a lot do with the size of the company. For a smaller company, I think systems like that are overkill, the number of jobs and the number of different people working on them don't warrant such detailed naming conventions. But hey, that is just like my opinion, man.
i believe office standards are a must have. when there are no standards, mistakes are made and sometimes, that leads to trouble (meaning litigation).
whatever naming convention and folder structure you use, the main point is to have discipline to stick to it. most of the conversation so far is about drawing files but don't forget other things like memos, letters, studies, correspondence with consultants and clients, etc. also, email is a HUGE issue for filing, especially when working on projects with a team (which is almost all projects). being able to share that information, archive it and search it are crucial.
keep in mind that there is also a hard copy filing system that should be created and maintained. we have a retention policy that differentiates between electronic files and hard copies and what needs to be kept for each. there are different retention requirements depending on the cliient (private vs. government as an example).
CADD or drafting standards are only one aspect of having office standards.
the importance of file standards is to allow folks to find stuff, even if they didn't create it. I always told my interns, it doesn't matter how you save your files, as long as somebody else can figure out where and what each one is. It's not about the drafter in the midst of a project, its about somebody 5 years later.
Synergy, that's entirely the point of using a key.
The only thing that matters is the first R.0034 part.
All the other data is extraneous to a certain extent. The only reason to have such a complex naming convention is you want to do analysis of your projects in a quick and timely matter.
Of course, if you use one of them big expensive project management and scheduling systems... a lot of this stuff is handled already.
However, the cost of one of those programs for even a small to medium-sized is so prohibitively expensive that you could hire a administrative assistant/file clerk, pay them $55,000 a year and still have enough money left over to refurnish the office.
UG, I really like what you're getting at although I think it could be simplified per Syn's concerns.
Regarding the use of a project key:
Would it make sense to have the project number first followed by the project type signifier? For example. 0034.R. This way projects are always listed numerically (chronologically we would assume) yet each project type would also be incorporated into the naming convention for reference. A master list of each project type and one letter signifier can accompany the proposed manual.
I agree, less is more is probably the better road when establishing a standardized folder structure. I'm hoping to continue fine tuning the one I have been creating and post it when done for comments.
I've worked at offices that are extremely well organized as far as drafting standards, to an office that has standards, but now one is following them, and a guy who has been there for 20 years is always complaining that his office is not following standards, it took him 20 years to figure that out pretty bad.
jmanganelli, Thank you for posting the folder structure! A quick question: How do you deal with correspondence? As I see it there are a couple of different layers of this. One is owner/client correspondence. Another is Contractor correspondence (this might be located in a CA or CD folder). A third is consultant correspondence. All three of these examples can cross multiple project phases. Also, each consultant obviously needs their own folder w/ potentially a "Sent", "Received", "Drawings", "Documents" folders.
ideally I'd like to not see the folder structure go more than 3 folders deep. I'm also interested in using numbers in the names. Your example uses a system a little different than I've used recently (although I have seen it in other offices). per your example: main folder headings are 100, 200, 300, etc secondary are 101, 102, 103, etc. In your system, how do you number third or even fourth tiered folders?
Currently I'm using a 0.1, 02.0, 03.0 Main Folder, 01.1, 01.2, 01.3, etc secondary, 01.1.1 third tiered folder (although I don't really like this format, it looks like a date!)
Drawings are typically named: "Proj#" "Project Name" "Phase" "Date(if archived)" (20102381.00 Community Center CD.rvt)
Letters, transmittals are named: "Proj#" "Type of Correspondence" "Recipient" "Date" (20102381.00 MEMO GC 082810.doc)
The naming is short and sweet. I'm not a big fan of using 100, 200... prefixes or labeling the folder tier. Name the folder what it is.
We developed a folder template with the folders preset and with templates for transmittals, submittal review, spec covers, etc ready to go. It's simple to naivigate and new people understand it their first hour at work.
ether, i suggest you look into newforma. with it, you create a searchable email archive. it very quickly searches email by keyword. no need to create an elaborate folder structure. i've never lost an email using it. it sounds like with the folder system you are proposing you will spend half your day organizing email. the easier and faster you can search and retrieve information the better. you can also use newforma to organize all of your incoming-outgoing transmittals, submittals, rfis, etc. i don't know how much it costs, but before you invest too many hours into this task, it may be worth exploring first.
i agree with won. i looked into newforma a couple years ago for our firm and was thoroughly impressed. but we didn't go that route b/c i think that was as the economy was becoming unstable.
if you have to do it without, and in answer to your earlier question about how we managed correspondence, here you go.
in outlook, for each project #, each person sets up an individual outlook data file and locates the data file in the correspondence folder with the proj# and their initials as the file name --- that is, emails are not allowed to reside on the person's c drive --- within that particular data file (accessed through outlook) there is a subfolder for each consultant, owner, owner's rep, GC, etc --- as emails are opened or as emails come in and are dealt with, the firm policy is that they must be moved from general inbox to project inbox (or some people set it up so they go right into a project inbox if they come from a certain person or have certain keywords)---now all email correspondence for that project is stored in the project folder by person's initials without much effort
this is how most of the email correspondence was tracked, just with outlook, without taking much time to sort and track --- there were also folders for each consultant though. this is for two reasons --- first, phone messages (if stored) or notes of phone conversations or personal conversations or formal snailmail letters are placed in the correspondence folders --- second, every now and then an email shows up so important that as soon as you receive it you know it is critical to preserve a copy --- perhaps someone signing off on something --- so these sorts of emails get copied into a word document and stored in the correspondence folders as well
Some naming conventions I like (BTW-this is a small company system):
-use the date at the beginning of the name starting with the year "10_0827" This helps if the file needs an official date different from the created date the os assigns. The year our front keeps august 09 from being next to august 10 when sorted by filename.
-name projects by the first three consonants of the clients name "TDC"
-follow that with a description of the document so you'll have some idea of what it is when you are looking for it 2 years later
"Once you download the email attachments where do you put the documents?"
If the outlook data file is located in the project folder, then all attachments you receive are located in the project folder by default at a minimum.
If you download and manipulate the files or you want to store specific files where anyone can get them, then they get saved into the correspondence folder or the submittals folder or the RFI folder, etc, as appropriate.
Aug 28, 10 5:38 pm ·
·
Block this user
Are you sure you want to block this user and hide all related comments throughout the site?
Archinect
This is your first comment on Archinect. Your comment will be visible once approved.
Office Standards
I’m in the process of assembling several procedural office standards for the 20ish firm I’m currently working for. This includes organizing project folder structure, establishing document naming conventions and developing standard cad library blocks, among other things. This firm has been around for many years and has managed thus far with little or no standards. In most situations, when there is a need, colleagues grab stuff from previous projects. Over time some pieces of this assignment have developed while others have been ignored. I’m hoping to not to start from scratch. My previous experiences, coupled with research are providing me with a good start. I am also incorporating any current office practices that could be considered the makings of a standard.
I’ve spent the past day or so compiling interoffice digital material, researching the web as well as compiling fragments from my former projects. I’ve found some good resources thus far. The AIA Best Practices section has been very helpful. The section on Project File Organization provided exceptional insight. Also, some of these threads and documents from websites have aided my task.
site 01
site 02
site 03
pdf 01
augi forums
pdf 02(19 mB!)
Essentially, the final drafts will need to be a collaborative effort. I plan on sitting down with co-workers over the next few days to get their insight and feedback. In the end, I will draw up a proposal and present the “package” to the firm principles. I’m hoping they will in turn offer their insight and critical feedback as the process moves forward.
Before I sit down with my colleagues, I’d like to do as much scouring and groundwork as possible. This inevitable leads me to the trusty archinect audience. I’d like to get some feedback from any readers that have had any experience in completing such a task. Specific areas I’m looking for insight into are:
1. Folder structure for your projects
2. Naming conventions – in the past, I’ve found it helpful to always try to include project numbers (at the beginning of the file name) in any document created (word, excel, dwg, etc). This allows for easy reference and retrieval down the road.
3. Any specific standards you find vital to the fluidity of your office operations.
A few additional notes:
I’m somewhat familiar with ISO, although I don’t think considering it for this office is feasible at this time. However, I am welcome to gleaning any bits and pieces of information if there are any worth the effort. The CAD library is something that will take a bit longer to develop and really a side project. The firm is considering incorporating Revit in the near future, so I do not want to spend a lot of time assembling blocks, etc. when Revit provides a lot of that internally. But with that said, I’m hoping some of my effort can spill over into this introduction and help guide the program towards an easily standardized tool. I see office standards certainly as a rigid and productive practice but good ones are able to easily incorporate new information into the fold.
Thanks!
I like to include the date in file names, 08252010 for example, just like the project number, it can help you locate something quickly. There are exceptions to this one though, Don't have a changing date in the name of files you plan to send out for others to use as an Xref. There is nothing worse than receiving a bunch of architectural details all with a certain date in the file name, and then 3 days later, getting new drawings with all new dates, you have to change every reference in every drawing instead of just copying over the old file!
As far as the general concept, I'm curious, who here works in an office that maintains strict office standards? Has it always been that way?
I've actually never seen strict standards. My office is much like how your's sounds, Ether. People pull a lot from previous jobs and adjust as needed. Unfortunately some crap details can get pulled along for the ride. Usually we are good at weeding them out, but it is funny how we end up correcting the same mistakes over and over.
For my office, I think the only way it could change is if the highest up person designed and implemented the standards, then they would follow the standards, since they came up with them, and they would be able to make others follow them. For me, If I come up with standards, no matter how good they are, I'd have trouble getting others to follow them, especially when things get busy.
Synergy, Thank you for the feedback.
I agree dates help in file naming structure in many situations. When I add dates to files, I put the two digit year,two digit month and two digit day, in that order. For example, August 25, 2010 is 100825. This way computers always put them in chronological order when organized by name (especially when spanning multiple years). This by the way is the type of conversations I've been having in my head the past couple of days (how and why sort of stuff). So when I propose these changes, I will hopefully have thought about it enough to answer questions and, well, sell it!
I think in most cases the situation depends on what the strict standards are. One thing that drives me crazy is to open an AutoCAD drawing and the original drawer only uses a handful of the "standard layers" supplied yet their is a whole range of colored lines within the drawing. The drawer simply changed one line "by color" and then copied or matched properties on the rest. Another example is importing blocks that do not have all of the elements on the 0 (zero) layer. Both examples can be a nightmare when trying to isolate specific layers or to making changes to the visibility of the drawing (think xrefs).
In a way, I think I posted this thread to also get some feedback on what are important standards? In other words, what should I spend most of my time developing and what should I spend the least developing? What will be a worthwhile standard to champion and establish? I am the "new" guy in the office but I do have the principles backing in this endeavor. They have wanted to do this for a long time but never put forth the effort. When I started working at this office, it was a nightmare for me to find things. Each project has a different naming convention and a different file structure. Everyone is aware of the faults but there has been no progress to fix the situation!
Thank you, ether, I also run my dates that way (and incorporate them into the beginnings of file names) and have always been frustrated to never find anyone else who agrees with that dating system. It takes a little bit of time to get used to but in the end it is a breeze and it helps keep everything so neat and organized... lovely. Just chiming in with my 2cents.
Yup, I know the feeling. I'm well aware of the benefits of having organization, It is just than in my experience, it goes out the window when people get busy.
Like I said before, don't adopt a naming convention that causes your basefile name to keep changing, I don't know how many times I get a file like Baseplan08202010.dwg from my architect and then baseplan08242010.dwg shows up a few days later and I've got to change all my xrefs. On a small job it is just irritating, on a big job, it is a huge waste of time.
"...I think I posted this thread to also get some feedback on what are important standards? In other words, what should I spend most of my time developing and what should I spend the least developing? "
I think time spent on the drawing standards should be monitored very carefully as you can spend a lot of time here and the practicality of enforcement may mean your efforts yield limited returns -- if some people are very set in their ways, if skill with CAD is uneven in the office resulting in the sets produced by different people being of very different nature and if the drawings are passed back and forth with consultants freely, enforcement can be impractical
the year convention you use I find to be the best --
year_Proj#_Author_Type of document (abbreviated)
with respect to where to spend time, are you also making recommendations for how the firm tracks/documents email correspondence? and what about CA documentation? meeting minutes? phone calls? RFI's? Change orders? Submittals?
I've found proper procedures for tracking these more useful and somewhat easier to get people on the same page about than drafting standards.
haha yeah cad standards have to be the toughest. In my office, we basically have two sets of drafting standards, one for each associate, if you are doing a job for Peter you better follow his standards, and of course David has own theories on how things should be done. For us it is mostly a source of comical tension rather than serious argument, but it can be a little annoying.
(fyi I changed the names in the above)
You bring up some very important points, jmanganelli. Yes, I believe this is the beginning of a way to standardize all of the documents coming in and out of the office. It will be a way for everyone to access the same information with the same working base knowledge. That's the benefit and goal of standardization, right?
CAD is only one facet of the application of standardization and one I'm certainly the most facile with. I'm aware of my idiosyncrasies about the program and can complete tasks while respecting my colleague's idiosyncrasies about it as well. But when I need to retrieve information from a drawing on a project completed several months ago (or years!), it's next to impossible to do it without help. If the folks who worked on these projects were not around to offer guidance, the firm would be in big trouble.
I think, by examining the file naming conventions of AutoCAD for example, or even viewed more broadly how we utilize it as a tool in the office, this can be applied in similar ways to other facets of the standardization process.
Also, I agree with monitoring my time closely but if implemented correctly, standardization can in the long run save offices (more) time and money!
Does anyone mind sharing a working folder structure they feel works well? I hope to have my working version posted in the next day or two.
Ether, I am highly suspicious if we work in the same office, except the timing of some details are off - our stories coincide too well :)
Our office has grown rather tremendously this last year *knock on wood*, and what with all of the new people, our principals decided to look at standardizing. They approached it by creating a "Best Practices" group of 4-5 employees (new and old), charged with sorting out and coming up with standards.
So far it's been a mixed bag. The group has come up with good ideas, and have proposed them to the principals. Right now the largest challenge is not coming up with standards, but actually getting a final go ahead. I don't know if it's really low on their radar (which is potentially understandable, they are after all running a business), or if they are fearful of change/implementation, or what. But it's been a "hurry up and wait" situation, and without any momentum the group has turned stale. Be warned of that battle. Or be very proactive with the principals, assuming your level/relationship allows that.
We also name/date our files as you do, year/mo/day, for the same reason (sorting). We've spent time on our project file organization, and generally, after reviewing some of those from people's previous firms, chose to go the "less is more" route. We've seen some folder trees that go on forever, and while being all-inclusive, at the end of many projects you end up with many empty folders. What's worse are the "grey" documents, that could be filed in multiple folders - thus causing the user to waste time going through empty folders until he finds the right one his workmate thought it should go in.
Instead, we've created a core number of folders, and if the situation arises the PM can of course create the one-offs.
"Everyone is aware of the faults but there has been no progress to fix the situation!
Same in our case. I propose the following reasons: the old guys have learned where everything is in quirky place, so they have no need to change at that point. Secondly, with smaller firms, I've noticed principals/owners get antsy if the time your spending is not billable.
On a related note, in my experience as a firm hits the 20+ mark it really reaches a critical mass where standards need to begin to be looked at and introduced.
While standards are/can be rigid, and can be thought to potentially go against the free-flowing movement of design, one of our guys came up with what I thought was the right approach: "Let's just get to the point where we can focus on architecture." Ie, people shouldn't have to spending their time looking for the office graphic standards, or doc templates, or what colors the office uses, or cad blocks...they should know where all of their "tools" are, so that they can concentrate on actually designing/problem-solving.
Another perspective one of our principals wanted us to understand: standards are not the end-all-be-all. If the situation warrants doing something new/if following the standard doesn't look right/fit the situation, then he wasn't going to hold it against us. He'd much rather have us think about our drawings rather than following rote standards, regardless.
I touched on some of the priorities you should focus on. Even though we also are switching to Revit, it's not going to be the whole office over night - just one project at a time. I imagine the route we're going to take - what with the existing CAD projects - that it will take at least a year to get the whole office on to Revit. Therefore, I think it would still make sense to standardize your CAD for that period of time. At least have something written down, so that when you switch over to Revit a template of the ideas touched upon is already in place.
Secondly, while architects produce drawings, the amount of time spent on project management runs a close second. Make sure your office knows which documents to use for what occasion and where they are kept on the server. There's nothing worse than someone looking for an affidavit to re-use in an old project, or the company designed punch-list, or RFI/Submittal/ASI logs. Searching for documents (for anything) is such a time sink. That's what your fighting.
That's pretty much it. I would like to go off-topic a bit and discuss the office library. In my experience it is never either a) organized or b) that organization is relayed to the rest of the office. I also think it goes back to the "billable" time issue - as in, they pay you to work, not to research, learn, and read. Complete opinion there, of course. But I've just never felt welcome to check out what's in there (around the office). It always seemed that if you have time to check it out, you have time to draft/manage. Anyways - if the Internet isn't enough deterrent (people researching there), then make sure everyone in your office knows what's in the library (both materials and books/references).
pick, what great insight! Thank you!
(headed home in a few minutes so will comment asap but would like to see what your comments stir up!)
cheers
after working in four firms, the folder structure i found most useful was one folder for all base plans -- each one named PROJ#_BASEPLAN_ARCH or PROJ#_BASEPLAN_CIV (or better, PROJ#_BP_ARCH, PROJ#_BP_CIV to save on characters) --- then the onus is on individuals to make sure there is only one baseplan at a time, not several with different dates, (though to some extent this is inevitable)
the file structure is something like proj#/folder#/task#/disc#
for instance something like this:
010034/100/101/03 means the project is the 34th project in 2010, i am looking in 100 series folder which is admin, I am looking in the administrative file, "correspondence," and I am looking in the structural discipline folder 03 which means correspondence was with the structural engineer
the phase numbers go something like
100 admin (101=correspondence, 102=contracts, 103=mtg minutes, 104=hours, man-hour, timeline & milestone projections, proposal, RFP's, permitting, billing, studies, marketing, reimbursables)
200 program & concept (program, budget estimates, concepts, preliminary code review, baseplans)
300 SD (base plans, floorplans, elevations, sections, outline spec)
400 DD (base plans, floorplans, large scale floor plans, elevations, sections, details, draft specification, FFE, interiors, specialty, consultants dwgs)
500 CD (base plans, floorplans, large scale floor plans, elevations, sections, details, specification, FFE, interiors, specialty, consultants dwgs)
600 BIDDING (RFP, list of bidders, RFI's & responses to RFI's, addenda, bid documentation)
700 CA (field reports, submittals, approvals, change orders, field documentation)
800 POE (evaluation tools, results, summary)
900 MISC
1000 PHOTOS/RENDERINGS/PROMOTIONAL MATERIAL
This is actually in my domain of expertise for once!
As for numbering, I agree with the general sentiment.
However-- and this is a big however-- your file naming system should not only be an organizational tool but an also an indexing tool.
And unless you use something like the ISO system where the concept is generally universal, inventing your own system generally leads to disaster unless this is someone's full-time job.
When it comes to the filing part -- which all firms should keep paper copies as your data as a tangible legal liability-- many of these file naming conventions do not translate over very well.
In electronic databasing, individual files within a larger organization typically have a key... meaning that all other aspects of the identifying information can be optional. The key is what makes it unique and also be able to have more than one name.
The key is what can make this both a filing system and an index system.
For architecture--
I'd assemble file names this way:
Project type (Project Serial) (Project Location) (Client type) (Client Initials) -- (Date) -- (Document Name) (Document type) (Document Author) -- (Status/Additional)
Example:
R.0034.EX.DC.RJ_100304_ELE.DD.MJ_PRE.NA
Translated:
Residential. 34th Project. Exterior. Direct Client. Client: Ryan Jameson -- March 04, 2010 -- Elevation, Design Document by Michelle Johnson: Preliminary-- Not Approved.
This primarily works because the only thing that matters is the R0034 part.
What if it doesn't have a date, an author, what if data is missing? What if certain aspects of the project can't be quantified?
It also works in filling better because it allows you to file by project type, then sequential order of project (F.I.F.O-- First in, First out!), then by client name and then by date.
very cool, unicorn. is this done with MS Access? or some other database tool?
Yes, you could do it with access or you could even write your own SQL database.
You could even file it manually.
The thing I dislike about arbitrary filing systems like ISO is that there maybe actual logic behind it... but it isn't "object" oriented so to speak.
Organization of libraries is pretty similar to ISO except that in addition to a numerical organization, the various numerical organizations are broken down into topics. So, even if the system isn't being categorized purely by number, the system is organized by type followed by the number categorization.
In that sense-- unless what I know what the corresponding numbers are-- I'm going to be looking for object or object types to locate a file.
The other problem with filling by date is what happens when you have 3 concurrent projects for the same client? Would you know the exact dates of each individual project?
What if you want to cross reference all direct client (one-on-one) healthcare projects done by Michelle Johnson?
If you can at least keep a spreadsheet (doesn't even have to be a database), you can track information much better.
Unicorn, when you send a drawing with that file naming system to a consultant for them to use as an Xref, how do they respond?
I find it really irritating to have to decode someone's intricate naming system, no matter how logical it is. I want a name that is relatively short and to the point, this is very cumbersome.
Like others noted, I guess it has a lot do with the size of the company. For a smaller company, I think systems like that are overkill, the number of jobs and the number of different people working on them don't warrant such detailed naming conventions. But hey, that is just like my opinion, man.
i believe office standards are a must have. when there are no standards, mistakes are made and sometimes, that leads to trouble (meaning litigation).
whatever naming convention and folder structure you use, the main point is to have discipline to stick to it. most of the conversation so far is about drawing files but don't forget other things like memos, letters, studies, correspondence with consultants and clients, etc. also, email is a HUGE issue for filing, especially when working on projects with a team (which is almost all projects). being able to share that information, archive it and search it are crucial.
keep in mind that there is also a hard copy filing system that should be created and maintained. we have a retention policy that differentiates between electronic files and hard copies and what needs to be kept for each. there are different retention requirements depending on the cliient (private vs. government as an example).
CADD or drafting standards are only one aspect of having office standards.
the importance of file standards is to allow folks to find stuff, even if they didn't create it. I always told my interns, it doesn't matter how you save your files, as long as somebody else can figure out where and what each one is. It's not about the drafter in the midst of a project, its about somebody 5 years later.
Synergy, that's entirely the point of using a key.
The only thing that matters is the first R.0034 part.
All the other data is extraneous to a certain extent. The only reason to have such a complex naming convention is you want to do analysis of your projects in a quick and timely matter.
Of course, if you use one of them big expensive project management and scheduling systems... a lot of this stuff is handled already.
However, the cost of one of those programs for even a small to medium-sized is so prohibitively expensive that you could hire a administrative assistant/file clerk, pay them $55,000 a year and still have enough money left over to refurnish the office.
Thanks again everyone.
UG, I really like what you're getting at although I think it could be simplified per Syn's concerns.
Regarding the use of a project key:
Would it make sense to have the project number first followed by the project type signifier? For example. 0034.R. This way projects are always listed numerically (chronologically we would assume) yet each project type would also be incorporated into the naming convention for reference. A master list of each project type and one letter signifier can accompany the proposed manual.
I agree, less is more is probably the better road when establishing a standardized folder structure. I'm hoping to continue fine tuning the one I have been creating and post it when done for comments.
I've worked at offices that are extremely well organized as far as drafting standards, to an office that has standards, but now one is following them, and a guy who has been there for 20 years is always complaining that his office is not following standards, it took him 20 years to figure that out pretty bad.
Go for ISO certification.
jmanganelli, Thank you for posting the folder structure! A quick question: How do you deal with correspondence? As I see it there are a couple of different layers of this. One is owner/client correspondence. Another is Contractor correspondence (this might be located in a CA or CD folder). A third is consultant correspondence. All three of these examples can cross multiple project phases. Also, each consultant obviously needs their own folder w/ potentially a "Sent", "Received", "Drawings", "Documents" folders.
ideally I'd like to not see the folder structure go more than 3 folders deep. I'm also interested in using numbers in the names. Your example uses a system a little different than I've used recently (although I have seen it in other offices). per your example: main folder headings are 100, 200, 300, etc secondary are 101, 102, 103, etc. In your system, how do you number third or even fourth tiered folders?
Currently I'm using a 0.1, 02.0, 03.0 Main Folder, 01.1, 01.2, 01.3, etc secondary, 01.1.1 third tiered folder (although I don't really like this format, it looks like a date!)
cheers.
ALL file names begin with the project number.
Drawings are typically named: "Proj#" "Project Name" "Phase" "Date(if archived)" (20102381.00 Community Center CD.rvt)
Letters, transmittals are named: "Proj#" "Type of Correspondence" "Recipient" "Date" (20102381.00 MEMO GC 082810.doc)
The naming is short and sweet. I'm not a big fan of using 100, 200... prefixes or labeling the folder tier. Name the folder what it is.
We developed a folder template with the folders preset and with templates for transmittals, submittal review, spec covers, etc ready to go. It's simple to naivigate and new people understand it their first hour at work.
ether, i suggest you look into newforma. with it, you create a searchable email archive. it very quickly searches email by keyword. no need to create an elaborate folder structure. i've never lost an email using it. it sounds like with the folder system you are proposing you will spend half your day organizing email. the easier and faster you can search and retrieve information the better. you can also use newforma to organize all of your incoming-outgoing transmittals, submittals, rfis, etc. i don't know how much it costs, but before you invest too many hours into this task, it may be worth exploring first.
Thank you, won. Email is just one area this process touches upon and incorporates.
i agree with won. i looked into newforma a couple years ago for our firm and was thoroughly impressed. but we didn't go that route b/c i think that was as the economy was becoming unstable.
if you have to do it without, and in answer to your earlier question about how we managed correspondence, here you go.
in outlook, for each project #, each person sets up an individual outlook data file and locates the data file in the correspondence folder with the proj# and their initials as the file name --- that is, emails are not allowed to reside on the person's c drive --- within that particular data file (accessed through outlook) there is a subfolder for each consultant, owner, owner's rep, GC, etc --- as emails are opened or as emails come in and are dealt with, the firm policy is that they must be moved from general inbox to project inbox (or some people set it up so they go right into a project inbox if they come from a certain person or have certain keywords)---now all email correspondence for that project is stored in the project folder by person's initials without much effort
this is how most of the email correspondence was tracked, just with outlook, without taking much time to sort and track --- there were also folders for each consultant though. this is for two reasons --- first, phone messages (if stored) or notes of phone conversations or personal conversations or formal snailmail letters are placed in the correspondence folders --- second, every now and then an email shows up so important that as soon as you receive it you know it is critical to preserve a copy --- perhaps someone signing off on something --- so these sorts of emails get copied into a word document and stored in the correspondence folders as well
let me know if you have questsions
Once you download the email attachments where do you put the documents?
Some naming conventions I like (BTW-this is a small company system):
-use the date at the beginning of the name starting with the year "10_0827" This helps if the file needs an official date different from the created date the os assigns. The year our front keeps august 09 from being next to august 10 when sorted by filename.
-name projects by the first three consonants of the clients name "TDC"
-follow that with a description of the document so you'll have some idea of what it is when you are looking for it 2 years later
10_0827 TDC Meeting notes about useless stuff.pdf
10_0822 TDC Permit Set.pdf
"Once you download the email attachments where do you put the documents?"
If the outlook data file is located in the project folder, then all attachments you receive are located in the project folder by default at a minimum.
If you download and manipulate the files or you want to store specific files where anyone can get them, then they get saved into the correspondence folder or the submittals folder or the RFI folder, etc, as appropriate.
Block this user
Are you sure you want to block this user and hide all related comments throughout the site?
Archinect
This is your first comment on Archinect. Your comment will be visible once approved.