One thing you can do that will help your team immensely is to organize your design files and related documentation. This one thing will help reduce your stress level immensely, especially when you have to go back and look at those files after you haven’t worked on the project for a while. Thanks for letting me share my experiences and thoughts with you.
———– Transcript —————————————
Audio File: 2014 Feb 26 – How to Organize Your Project.mp3
Good morning. My name is Montie Roland. I’m with Montie Design in Morrisville, North Carolina.
And this morning what I’d like to talk about is how to structure your project from a file standpoint, from an organizational standpoint.
Montie Design is a full-service design firm in Morrisville, North Carolina. We provide industrial design, mechanical engineering and prototyping capability on-demand to help you move your project from concept to ready-for-the-shipping dock.
It’s always good to have processes and procedures. And, of course, any company can take that too far. And the counterpoint is if you take it too far, then you get that big company mentality and you’re painful to deal with. But, a lot of these processes and procedures benefit the company. And I’ll be the first to admit that as we’ve grown . . . I’ve not been the biggest proponent of procedure and process, because as a small group, you get everybody reading your mind and you don’t have to worry about it. But this changes as you have more employees, because of different levels of capabilities. You have to keep retraining. And so all of a sudden, it’s more important to have policies and procedures just to make life easier for your staff.
It’s also important when you think about interns. You got somebody that’s going to be there for a limited amount of time – you want to get them in, get them trained and get them some experience, and then also get some work product completed so it’s a win-win for both the employer and for the intern.
So let’s just dive in. A lot of these topics I’ve covered in past podcasts were much more higher level. And so, in this case though I want to dive in and let’s talk about this in detail. So, first thing is that, when you think about how do you organize your files, you want to have a place that everybody can get to. So, let’s say, let’s call it the \Z drive. And on the \Z drive, you have a space that is a shared working space. Now, what you need is you need a set of rules so everybody knows what to do. On a project where there’s more than one contributor, you really want to have a gatekeeper. So the gatekeeper is in charge of files that go in certain locations. One is that files that go in current design and the other is files that go in your release directories.
So, let’s kind of roll through those directories so I don’t get too far ahead of myself. The current design . . . well, back up. So, we’ve got a project directory, and let’s say our project is Zigzis (spell that one). And so I’ve created a directory, in this case; maybe for the client of Zigzis. And then I have to make decision. Is it likely I’m going to have multiple projects from this client? Or is it likely that I might just have one? Or that not now. So maybe what I’ll do is that I’m thinking that this might be a repeat client. So let’s say that, if it is, then I’m going to want to have a directory for each project that we do for that client. So, we’ve got a directory called “Clients” and then the client name; and then underneath that, let’s say Project A is the vertical inductor. So we create a directory called “Vertical Inductor”. Alright. And under Vertical Inductor, we’ve got several directories. And what we try to do is keep these file names the same so that its consistent for everybody. Otherwise, you run the risk of people not knowing where the correct file is, which could be really, really bad. Because if you don’t maintain control over where files are placed, then you end up with names like “12 February 04”; “13 February 04”; “29 November”, or “Latest”; “Latest Old”; “Latest New”. So you can imagine that someone stepping who isn’t the person that created those directories is not going to have a clue which is the correct set of files. Same thing for the person who created them; comes back six months’ later, may go, Ahh, I don’t know. And the scary part is you might grab the wrong files. Let’s say you grab the wrong files and made some parts. You just made some scrap metal, potentially. Or worse than that, it may take you a while to figure out what’s scrap metal and what’s not, and that may be more expensive than just doing the whole thing again. So, in order to avoid that entanglement, what we do is to have a directory called “Current Design”. Current Design is the working directory. After the project’s over, the files in Current Design, theoretically, should be the latest, but may or may not. But while the project’s active, Current Design should always have the up-to-date files. And that’s not necessarily released but that’s the current working files (and by “working files” means the ones you’re working on). Maybe if you just released and maybe those are the latest, same as the released, but if you’re between releases and your Current Design is the directory that you’re using to pull files out of.
Now, once you get a lot of hands working on a project, it’s always good to have a gatekeeper. And the gatekeeper is the person who controls what goes in Current Design. So, he may have ten people providing files to him, and then he turns around and puts them in Current Design. We also have a directory called “Released”. Released contains files that have been released. And what released means is its gone out to the vendor. Because most of the time we’re operating in a development mode, our release policies may be a little different than your release policies in a large manufacturing facility, or in any manufacturing facility. Because what we do is every time a drawing goes out to a vendor, we bump up the rev. In absence of a specific revision policy, what we do is we go up by numbers. So, we’ve got a part number and then the revision starts at 00, goes to 01, 02, 03, 04, 05 – so we can have a release at 07, a release at 12, a release at 99; don’t care. So one of the things is I think it’s important to keep in mind is that your revision number structure is something that someone eventually picks. And as long as it works for you, it just doesn’t matter. It just needs to be consistent. You can do A.1, A.2; we’ve seen that. You could do a major release is A; a minor release is numerical. So, it could be A.01, or A01. Or we just think it’s easier just to – 01, 02, 03, 04.
Now, whenever we release a drawing to a vendor or send it out to someone who may use that to make a part, then if we make changes to that drawing, we revise that drawing. If the change is very, very small, i.e., does not affect the final result that you get back, then maybe it’s not Rev’d at that point. So, for example, if you add a coma to a note that cannot possibly affect the outcome of the part, it’s just to fix some grammar, then maybe you don’t release that if you’re in the middle of development. At the end of a project, everybody has drawings; sure, you’ll need to Rev that.
So, the release directory – so we’ve got a directory called Released under our Induction Directory. And so then underneath that we’ll have “Rev (R-E-V) 01”. And so that’s our first release when we first send out drawings to someone, or to the client; call it “Rev_01”. The next time we have a release, we call it “Rev 02”. It’s important to note that part numbers and assembly drawn numbers may not necessarily align with this Rev 02 – Rev 03; it just means it’s the next time we released a set of drawings. Now, it may, depending on the client’s needs, there’s a possibility that we may Rev the top level assembly to match that revision in the directory. It kind of depends on where we are in the development process. But that way you always know that here is the latest and greatest that we’ve sent out. The Release directory also gives you a historical reference for what you’re working on. So that way you can go back and look at earlier versions of files if you need to. Hopefully, you never need to. But if you had a corrupted set of files, or something along those lines, you could. We also create “Concept” directories. And the Concept directories will have sub-directories underneath indicating which part of the project; so maybe if you did sketches for the rear mount, or the fascia, they might have separate directories. Usually we name concept sketches by date, which seems to work well, but that’s up to you. So usually what we’ll do is we’ll do “2014 Feb 24 – [and then the name of the concept] – so “2014 Feb 24 – Rounded Fascia Concept.PDF” or what have you.
The Concept directory is where you’ll store your sketches, your ideations; maybe your solid model concepts; pictures for your style board. So then, when you think about these files we’re starting to store, you really have two types of files: one type of file is parametric, and the other type of file is static; and then really, I guess a third file would be like a file that’s directly editable. So, when it comes to CAD files, though, we have two types. So, parametric files are files that are linked or potentially linked to other files. This is very, very important to keep in mind. So with SolidWorks, we can save a non-parametric file to a format like STEP or DXF or IGES or DWG or PDF. These non-parametric files can be edited – easily in the case of a DXF or DWG; less easily in the case of a PDF – and so these files, though, are generally not going to change . . . well, just because you change something somewhere else in the SolidWorks model. However, the SolidWorks file from SolidWorks are parametrically linked in many cases. So, for example, a drawing file is going to go reference the part file to rebuild the drawing. So, if the part file is missing, it can’t reference it and can’t rebuild the drawing, and you get basically a blank screen in the middle of your drawing. So this is very, very important to keep in mind. Whenever you move files from one directory to the other – and occasionally you need to do this anyway – you run the risk of orphaning a file that’s somewhere else. So, a good example of this is, let’s say that I am working on (in SolidWorks) and I go to McMaster Carr and I download a screw, which is a great way to get a screw. So, I download that screw and then I open it up; it comes across as a STEP or an IGES; and then I import it into my model. And when I hit Save, that McMaster Carr screw was saved to my download directory on my local machine. So, if I don’t consciously save that to my Current Design directory on the \Z drive, then what’s going to happen is that now I have files in two different places. So, if I was to go and grab Current Design and move it into Released, let’s say – just copy it over – I would leave that screw behind. Because the copy tool in Windows Explorer does not know about the relationships in SolidWorks, so it doesn’t know to go grab that. SolidWorks has this wonderful utility called Pack and Go. Pack and Go finds every file that’s linked to the files that you have open. So, what you want to do is go to the top level, of, let’s say, Drawing; or top level assembly. Open up Pack and Go, and it’ll give you some options. And generally, you want to exercise all those options in terms of including drawings, including textures, including decals, FEA results – grabbing all that’s good. That way you don’t leave something behind. SolidWorks will go look for those files, make a list of them, let’s you see that list, and then you pick a location where you either want to save that as a ZIP file, or you want to save that just to that directory; drop the files in that directory. So, you choose that directory and then you hit “okay”. Then SolidWorks will sync, and then it will start grabbing files and copying them to that directory. If you do not do this it will bite you. It is not a question of if it will bit; it’s a question of what moment, what day and how bad. Because we’ve seen this before. You can imagine that if you have files on a local machine and you just copy them over, or you copy them between places on the \Z drive or what have you, and you orphan some of these files, it can be very painful to find those, get those back. And then you’re never really sure you have the right one. So, let’s say you orphan a single screw. Okay, worse case, you can download it from McMaster again. But let’s say that you have somehow ended up with a part file that’s in an unknown Rev (or even if we know what the Rev should be), and maybe it’s in some directory. It could very easily happen that you inadvertently saved it to the wrong directory. So maybe you’re working in Current Design but you’re using a file from Rev 02; but that file is actually Rev 07. So you grab the stuff out of current design and move it to Rev 08; you miss the Rev 07 file. Well, now, all of a sudden, we’ve got no clue where to find that file. And it’s difficult to find without pulling up every single file in the subdirectory on the \Z drive and on your machine and try to figure out which one it is. And even then we’ve got to go by the revision number and properties, and that’s just painful because that still doesn’t tell us it’s the right one because there could be like a 7 here and a 07 here, and which one’s the correct one? If you do Pack and Go, you avoid soooo much of that trouble. Pack and Go is your friend. I just . . . this is one of those things that’s important to emphasize.
So, a similar thing applies to other programs. For example, PowerPoint has a Pack and Go feature; use it. Grab all of these images, put them in a Pack and Go file, because most of the time when you’re working on projects you end up with images in different subdirectories; it’s on a local machine; it’s on your network. But if you do Pack and Go it grabs all those and puts them in the same space. Yes, you use more disk space. I will argue that disk space is dirt cheap compared to a few hours of looking for a file you can’t find ten minutes before your deadline.
The same goes for, you know, when you’re working in any of the Adobe products. If you have the option to embed it in the file rather than link to it, embed it in the file. I realize this can make your catalog a gigabyte in size. But, it’s so much better than two months later pulling it up and missing files. There again, disk space is cheap; time’s not. So, embed those files, Pack and Go . . . you know, use these features in these programs so that it makes it easier.
Alright, so, it’s also important to note that you have a PLM system, and you do check-ins and check-outs. It’s going to be a little different because that software’s going to manage a lot of what we’re talking about. So, I’m not sure; I think it’s beyond the scope of this podcast to go in-depth on the PLM systems. And they’re great; they’re awesome. They help manage some of this. So, in this case, we’re just talking about the manual. But, on the other hand, if you understand the manual, it makes it a lot easier to understand the PLM.
So, we’ve talked about our Current Design, Released. Let’s go back to Released for a second and talk about reving assemblies or not to Rev assemblies. It’s going to be driven by several things. One is if your design changed dramatically and the assembly doesn’t look like the parts, you need to Rev the assembly. Other times you may need to Rev the assembly is if you have a vendor that has a PLM system that is tied to the assembly rev, and doesn’t have the flexibility to make a change to their drawing set without a revised assembly. We’ve seen that. We have a project right now we’re working on; they don’t have that control. So if we make changes, we have to revise the assembly, just because we revised a part. And the problem is that if you have to do that there may be a lot of subassemblies in-between, so it’s definitely a lot of work to do that. And so you’re kind of starting to see, as a manager now, why sometimes your engineers are reticent to do revisions, because there is some work to it.
So other directories that you’ll need, one is I create a “Project Management” directory. Project Management directory has contracts; has any schedules; things that you need in managing the project, but maybe not necessarily need to execute the design. So another thing we would do is that we want to create a Bill of Materials. The Bill of Materials is soooo handy. As the project goes along, your Bill of Materials is going to become a costed Bill of Materials. So at the end of the project what we want to see is we want to see a Bill of Materials that has a part number, a description, a revision, and has costing information. Now, depending on the project, there may be some projects where that’s completely handled by the client. For a MontieGear project, one of the last steps is to make sure that Bill of Materials is correct, has the costing information, and then, that is used by the person doing the pricing, which often is me for MontieGear. I will take that, and if that Bill of Materials is done correctly, what I can then do is add the cost of labor to do assembly; any shipping costs; and then I know how to price the product without going through and pulling up a bunch of drawings. And this is so important later on. It saves tremendous amount of time.
So as you go through the project, other directories you’re going to want to have is “Quotes”. So, anytime a quote comes in, scan it in. If its electronic, save it. Create a directory of your quotes from your vendors in one spot. So, that’s a subdirectory under your project directory. You’ve got Quotes. So we’ve done Current Design, Concepts, Quotes. Another one you’ll often have is something called “Files from Client”. And so those are files that the client has provided. These are documentation that where they’ve given you pre-project documentation; there may be initial version of a product specification. And so this is that repository of those documents. There again, a lot of times we’ll save those file names by date; if it’s a quote, we’ll save it by date and vendor, name, and then possibly, you know, what that is if it’s a single part quote. So you can quickly scan down that directory and find the quote for the lower left beam, or what have you.
And you may have other directories as needed. Those will depend with projects. One of the other things we do is create an “Images” directory; underneath it we’ll have a description of general what that image is about. So, it might be \images\first prototype; or date first prototype; date proof of concept; date alpha prototype; date beta prototype; date installation. So, that way you can scroll through there and very quickly find those images. It’s also a great place if you’re a manufacturer to also put your product shots, or your products in use; maybe they’re static images done is the light tent. But that way you’ve got a great way to go find that, because its tied to the project. So this project directly, theoretically, if you were to just copy that to a flash drive, it would have everything you need to continue with that project. And that’s good because over time hard drives change; files get deleted; directories get changed. But so if you encapsulate everything in that subdirectory, then that makes life a lot easier.
So, kind of to roll back through this, we’ve parametric files and we’ve got non-parametric files; and then we’ve got files that are often edited. And so, the parametric files are SolidWorks files that could be Inventor or it could be Pro-E. But those are files that need to be kept together; need to be moved using a Pack and Go. And occasionally with your current design, one way to make sure you have the correct files in there is to Pack and Go to a temporary directory; delete the files in Current Design, and then copy those back in. And that way you know you don’t have some superfluous files in there.
Other files that we’ll create and need to do something with are non-parametric files. So, these could be IGES, STEP, DXF, DWG. And these files, in the Release directory, it will have the parametric files – plus – a PDF of each drawing, and maybe a DXF or DWG as that’s needed to do a cutting process, a 2-D cutting process like water jet; or sometimes a machine shop, if they’re working from a 2-D file. Also have the 3-D non-parametric files, like STEP or IGES. And so that way, in that Release directory, you’ve got the CAD files, plus you’ve got the files you’re going to send out to vendors (the non-parametric files). Then probably this would be a good spot for your Bill of Materials for that rev. And so in this case a lot of these files follow the same format (for us, at least): it’s part number, space, dash, space, description, underscore, Rev (R-E-V-), space, and then the two-digit revision code (so, 00 or 02). And so we do this to keep these file names consistent so they’re easy to read through quickly. And that way you can very quickly figure out what you’re looking for. If you don’t maintain control over file names, you end up with file names that mean something to one person today; but may mean nothing to someone later. And, six months from now, may not mean anything to the person who named it then. So, I think it’s very important to maintain that control; have a strict doctrine over that.
That Bill of Materials, it’s important for costing purposes if you’re a manufacturer because that way your engineer is taking what they’ve learned when they went out for quotes (or the purchasing agent), so whoever went out for those quotes enters that into your Bill of Material so now you can do your pricing quickly without having to go look for a bunch of information which may be hard to find. Also, storing those quotes is valuable because then you’ve got a way to address that quickly, there again, without having to go look through emails or look wherever.
So, from a hundred-thousand foot view, what we want to do is we want this project directory to provide everything you need to pick up that project, modify that project, price that product, or deliver to a client. And if you can do that, then that helps multiple phases of the organization; not just engineering or industrial design, but also purchasing; it’s great for a reference later for sales and marketing because they understand what’s driving the cost. And it’s just a win-win all the way around. And that’s important, there again, to maintain that discipline because it’s not only helping in the engineering stage, like I said, you’ll reap benefits for the life of the product, especially if you ever have to go back and make a change or you ever have to go back and re-price or pricing on components. It’s a great tool. And having that in a standard format, it just benefits you.
If you have any questions about this, please don’t hesitate to give me a call. I know it was kind of a long section here and technical, but happy to entertain your calls, questions. It’s 1-800-722-7987. It’s Montie Roland. Email – firstname.lastname@example.org (M-O-N-T-I-E at M-O-N-T-I-E dot com). Or you can visit our website – www.montie.com. You can see the results of client work we’ve done at the montie.com website, or you can see some of our project that we’ve done for ourselves at MontieGear – M-O-N-T-I-E-G-E-A-R dot com). I hope this has been beneficial. Montie Roland, signing out.