How to Set Up a New Project for Your Design and Engineering Team – Part 1

After many years of setting up projects for our industrial designers and mechanical engineers, here are my thoughts on some basic best practices on how to structure your files and keep your project organized.

Victor Sketching

 

Here is the transcript:

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. Now, I think . . . 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. I’ll be the first to admit that, as we’ve grown, we’ve . . . 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 you have different levels, different capabilities, you have to keep re-training. 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’ve got someone’s who’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, 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.

So, we’ve got a project direction. Let’s say our project is Zigsess (spell that one). And so, we got the . . . so I created a directory in this case . . . maybe for the client Zigsess. And then I have to make a 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, not now . . . So maybe what I’ll do . . . 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 it’s 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 in who isn’t the person who 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, “Ah . . . 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. So, then . . . while the projects 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, it 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 your . . . 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 that controls what goes in Current Design. So, he may have ten people providing files to him; then he turns around and puts those 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 released 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 or release at 12, a release at 99.

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 can do . . . a major release as A, a minor release is numerical. So, it could be A.01 or A01. We just think it’s easier just to use 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 (and maybe it’s not rev’d at that point) . . . so, for example, if you add a comma 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; I’m 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’ll 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, depending on the client’s needs) there is a possibility that we may rev the assembly to match the top level assembly to match that revision in the directory. It kind of depends on where we are on 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 have a corrupted set of files, or something along those lines, you could.

We also create “Concept” directories. And that Concept directories will then have sub-directories underneath that 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 . . . so, we’ll do “2014 Sept 24 – “ and then the name of the concept . . . “Rounded Fascia Concept”, not PDF or what-have-you.

If you have any questions about this, please don’t hesitate to give me a call. It’s kind of a long section here and technical, but happy to entertain your calls, questions. It’s 1-800-722-7987. That’s Montie Roland. Email – montie (M-O-N-T-I-E)@montie(M-O-N-T-I-E).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 projects that we’ve done for ourselves at montiegear (M-O-N-T-I-E-G-E-A-R).com.

I hope this has been beneficial. Montie Roland, signing out.

Montie Roland

Montie Roland is President of Montie Gear, a manufacturer of outdoor sporting equipment in Sanford, NC. Montie is also employed at Pentair in Sanford, NC as a Mechanical Engineer on the New Product Development team. Montie enjoys finding innovative solutions to customer requirements. He has 15 years of experience engineering products in diverse market spaces including industrial, commercial and military. Montie earned a BS in Mechanical Engineering from North Carolina State University. He is also the President Emeritus of the Carolinas chapter of the Product Design Management Association (www.pdma.org/carolinas) and a founder of the RTP Product Development Guild (www.rtpproductguild.com).