Some mornings when I walk into work it takes me a while to organize my daily activities, get things setup, and start being productive. If I don’t have my coffee, this takes a bit longer. And if I forget my coffee, luckily I’m fortunate enough to have a cafe that sells the trusted Starbucks.

As with many other companies, we have a culture of Lean. We are always continuously improving and reducing waste; our target is getting more of that key word I mentioned: “Productive”. I have been involved with my fair share of project improvement strategies with mostly all of them requiring a return on investment (ROI) analysis for capital expenditures. Nothing is free, and usually always requires a significant capital investment. So, could coffee be considered an investment?

When I buy a $2 coffee in the morning, I feel better about myself that I’m contributing at a higher level, and it benefits me by making me feel better. I also do my company a benefit by getting myself productive and ready to make things happen.

When companies stare down the financials, many are blinded by the real driving factors that lead to those numbers. With quality metrics driving higher yield, the common idea is to find a solution that does more with less or, at the very least, more with the same. If some companies viewed coffee as a direct expense then they are missing the idea of ROI. With each $2 coffee, if someone provides more than 15 minutes of extra work in a day, they would have - even at minimum wage in California - a net positive return on investment. In a large organization this leads to potentially requiring less new hires. Instead of hiring one more engineer, maybe it’s time to buy 10-15 minutes of productivity - one cup at a time.

Ideas are cheap, but people aren’t. For those working on continuous improvement projects, or any process development activity, it is always easier to come up with a new process than it is to implement it. Having people adopt a new process is always the most difficult aspect of process improvement. When changing processes it requires people to learn how to do them (and spend company dollars while doing it).

Here in this post are some ideas to consider when designing process workflows to get your colleagues on board.

1. Path of least resistance

As with electricity, people migrate towards the path of least resistance. If what needs to happen aligns with the easiest way to do it, your colleagues will catch on quickly. If people tell you that new software won’t be successful unless the process is already successful, then they haven’t had successful alignment with the path of least resistance. Try to find assembly tools, software, or design features that help the person complete the task the way you want it completed, and you will end up with the intended outcome every time.

2. Intuitive Design

You already know the process because you designed it, but it doesn’t mean it’s obvious to everyone else. Garner feedback from a select few and take constructive criticism with a grain of salt. You might get some ideas on how someone expects your process to work before they know how it works. If someone can figure it out on their own, you save time and money.

3. Balanced loading

If your approval process includes sending everything in an approval workflow to the CEO, he probably won’t review things very critically. Try establishing early reviews with peers, and with successful peer reviews migrate approval up the ladder. There are more peers than CEOs, so establish balanced work loads.

4. Established work-arounds

Many will want to have a work-around for emergency or priority events. If you establish these work-arounds up front into the process, it can be tracked.

5. Make the process map available to everyone

If people don’t know the process, they may not take it seriously. Making process maps easy to understand and publicly available to everyone helps them understand the process for themselves.

Change, to many, is difficult to adapt to. The best way to implement change is to utilize technology to make things easier, ensure everyone is on board, and explain the rationale behind the change. Typically, it just takes a little transparency, constructive feedback, and some due diligence in planning it out. Processes should always be a work in progress, so don’t let the fear of change hinder improvement.

As important as quality should be in any company, it still remains a buzz word to many. Quality Assurance (QA) and Quality Control (QC) seem to be used synonymously. In this post I will attempt to define the difference between QA and QC, and the importance each role has.

In organizations with enough employees to have a quality department, the quality department usually controls most aspects of quality . These include managing the Quality Management System (QMS), creating and maintaining quality assurance plans, ensuring inspectors are screening parts for engineering conformance, monitoring product output and process capability, and auditing to procedures and standards.

Quality Types

With all these responsibilities there are clearly multiple roles within quality. Because of this, each role must contribute in different ways to cover the wide range of requirements.

There are two ways to ensure process outputs meet the intended output. The first step is defining output requirements (e.g. design drawings) and the second step is to define the process, typically using a procedure. Both of these fill the Quality Assurance (QA) role. QA covers the documentation and established rules for creating the output. Anything related to establishing the means and path to the desired outcome is covered under quality assurance. To contrast this, there is a screening process for all of the outputs created by QA. This is called Quality Control (QC)

Once a process has created outputs, the outputs should be inspected to verify it meets the original requirement. The Quality Control role fills the responsibility for auditing products (e.g. inspection). QC can be thought of as the gate keeper that filters out all products that should not travel on to the customer unless it meets engineering requirements.

The undefined bridge between Quality Assurance and the Quality Control is manufacturing. This is what I like to refer to as the Quality Making Department.

Configuration management is one of the highest priorities in a project. Utilizing a revision system helps keep electronic versions organized. Defense and aerospace customers typically always expect documentation to be associated with their delivered system, and those documents must reflect the correct configuration of the delivered system. Revision systems may be devised in many different ways of distinguishing different versions. In software, versions are numbered by “major, minor, alpha, beta and build number” but in engineering there is usually one revision number.

Engineering revision schemes will either be numerical increments, or alphabetical increments. Since there are two typical ways to revision engineering documents, which one would be better? A continuing poll by Solid Smack asked its users “Should Drawing Revisions Be Letters or Numbers?” Though the votes are not from a valid statistical sample, the results of this poll show they are not statistically different (p=.390).

Since engineering revision schemes cover many industries, there are often many ways of doing the same thing, but each has their place. When designing a revision scheme it is important to consider how the revision is stored in the system, how it is retrieved, how it is assigned, if a company global standard can be used, and what implications it may have if it were ever changed.

Revisions stored on drawings are best tracked with an alphabetical character if the part is using a numerical part number, such as “A, B, … ,Z”. The alpha character is very distinguishable from the number and has a higher chance of not getting associated with the part number. This system works great when there are less than 26 revisions for each part. When there are more than 26, the alpha character revision increments to “AA, AB, … , ZZ” which is less aesthetically easy to deal with, and within a PDM system, may or may not be difficult to administrate. However, a revision of a part should only be made when the form, fit, or function of the design is not changed. Revision changes include the addition of notes, clerical edits, or changes in the general drawing layout. A new part number should be created when changing the form, fit, or function. This should keep the limit of revisions under 26.

Software is a different matter. Typically small revisions are “build” versions. Software can be as small as an embedded program with a few lines on a chip with minimal memory. Constraints in software size may yield to the necessity of using a numerical revision. To know the software version, binary must be translated to base-10, which is much easier than to translate to alpha characters.

When determining a revision scheme, you must think of all of the ways it’s tracked, from small to big items, from documents to software to engineering drawings, from file folders and PDM to ERP systems. Don’t constrain yourself by the limited method of assigning a revision scheme. Flexibility should be expected.

On a drawing there is a flag note next to a hole with diameter, position, and perpedicularity callouts . The flag note reads “Key Characteristic per AS9103”. I’ve seen many clever ways to nnotate a Key Characteristic, be it a flag note, image of a house key, etc. But what is this Key Characteristic and how might a designer help someone understand what is important?

AS9103 defines a Key Characteristic for a part as “those selected geometrical, material properties, functional and/or cosmetic features, which are measurable, whose variation control is necessary in meeting Customer requirements and enhancing Customer Satisfaction.”

The “functional…features” apply to most drawings and Key Characteristics, but what is really intended to be done about this important feature? The definition leaves the intent quite vague. Many believe a characteristic is a dimension of a feature, and some believe it’s the whole feature. In the example above, the hole has 3 dimensions: diameter, position, and perpendicularity. Admit it. You’re thinking “Seriously? .0008?? How can I meet a Cpk of 1.33 on .0008?”

Is the perpendicularity dimension even included in the Key Characteristic? Because of AS9103 ambiguity, it is difficult to determine the intent of the designer by merely seeing a flag note annotating a Key Characteristic. As a manufaturer, it would be safe to say that the entire feature and all its dimensions are considered the Characteristic, but because there’s room for interpretation, the designer might not get what he or she wants.

There are a few options to define the engineering intent, but they all lead to furthering the requirement. As a designer, question your intended audience. As a manufacturer, question your engineering. Between controlling features or just its select dimensions, it doesn’t matter who is right. If more than one person can come to a different conclusion, define the ambiguity.

The old adage “If it ain’t broke, don’t fix it” seems to target those who have a history of breaking things. Why play with it if you’re just going to make it worse? Sometimes changing something that works is a poor decision, but after a while technology can pass you by. Without continual improvement, your processes may be a bit behind the curve.

Documenting processes is key to keeping them running. Add on continual training, machine maintenance, and calibration, and your manufacturing line may keep pumping out consistence product. So, if it ain’t broke, why fix it?

Continual improvement keeps the company advantage above competitors. Without believing that there’s a better way to do everything, someone else will find a better way. And chances are, they work for another company. The lean philosophy, preempted by the Toyota Motor Corporation, has a lot more in its culture besides reversing the way you move product through an assembly line. They involve many employees, mostly line level technicians, to help improve their processes.

Implementing a change typically requires social thinking and some ownership for those who will embrace the changes. The best way to garner ownership is to have the idea originate from the process owners: the guys on the floor. Starting kaizen meetings (continuous improvement meetings) helps keep technicians in the loop and empower them to help improve their own work. After giving them a chance to contribute, remember to show your appreciation.

So, you’re starting a new project. Chances are, with engineering projects, you’re going to create a lot of new data. If you’re going to treat the file structure of the project like you do with your personal computer, you’ll probably end up with a music folder, a document folder, pictures from the lake, and maybe a software folder (back-up of purchased versions, of course). So where should all your engineering files go and how should you divvy them up?

When it comes to the two extremes of engineering file hierarchy, there are two options: 1)By Department - Where each department gets a whack at creating their own content in their own folders, or 2)By Program - Where the program folder contains all departmental data pertaining to your project. Let’s break this down a bit and decide where to go.

If you decide to organize the folders by department, each department is going to have complete ownership of their own folder. The data in there can be organized how the department manager, or anyone who has folder permissions, decides to arrange it. Depending on some departments, this might increase productivity. The manager quickly knows where all the files are. Well, when the manager gets a new program, he’s/she’s probably going to make a new folder for the new program. This is where is gets whacky. The folders start to look…well, like your own personal computer again. And you’re probably sure that you never really thought out your folder structure. The department manager is probably not going to think it out either.

The other option is to segment the data by project. The customer owns their data and it’s easy to give them a status update, but how difficult are the folder permissions now? The IT administrator has to setup the permissions in each new program. Do you want your Manufacturing Technician getting a hold of financial data? This could be tedious.

Move over Windows, PDM makes it easier. If your PDM system allows permissions by folder name, a clever way to make permissions easy is to setup a standard folder hierarchy template. “Jeez, that could take eons to get it right” you’re thinking. But it really helps. Spending a few weeks planning and devising iterations of a folder template (at least the sub folders of the root project) make both data management, customers, and technicians happy.

I created this blog to post my engineering best practices topics. Here I intend to delve into many topics for engineering best practices and engineering methodologies. Hopefully you will find my content useful as I have decided to try to share as much of my knowledge that I have learned through the years. I have tackled many projects and have had to switch directions at times. So here I will help you decide which side you should start tackling a problem from. Please check back soon for more content!