comment 0

The Quality Habit, a Reflection

“Quality is not an act, it is a habit.” I’ve heard this quote attributed to Aristotle, though there is some debate about this.

Another variation of this quote is “We are what we repeatedly do. Excellence, then, is not an act but a habit”. But what does this quote mean for industrial engineers?


Habits are learned behaviors, something you intentionally start out doing and then maintain. Introducing best practices doesn’t matter much if you don’t implement them and stick with them.


Habits can affect one’s overall behavior, but it is that behavior that determines culture. That’s demonstrated by the axiom “One’s actions are a better indicator of beliefs than one’s words.” Management saying quality is number one is irrelevant if day to day decisions are contrary to that mantra. Conversely, management and employees whose actions are consistently of high quality and people mindful of such can maintain quality in operations and service delivery even if the culture isn’t specifically hyping it up.


Quality only gets better if you get in the habit of looking for ways to improve it and then train the new and improved methods to the point they become a habit. If you don’t monitor during the learning period and “sustain the gain”, people revert to the old ways, their old habits.

Habits can be good or bad. Bad habits can ingrain poor quality, such as shortcuts and rushing through the job. Good habits ensure high quality.

Good habits can become bad habits as things change. You need to re-evaluate your habits to see what you need to stop doing in addition to how to improve on what you choose to continue doing.

comment 0

IE and BI – the Intersection of Industrial Engineering and Business Intelligence

A classic Peter Drucker quote is “What gets measured, get managed.” A quote attributed to W. Edwards Deming is “You can’t manage what you don’t measure.” Big Data attempts to collect as much information as possible in the hope that the data can be used to make better decision. However, you will still fail if you don’t ask the right questions, give information to the wrong people, fail to give it to the right people at the right time or waste time trying to make sense of it all.

Many enterprises are struggling to manage the firehose of data they’re funneling in, much less mining it for useful information that might be turned into insight (wisdom). We’ve seen a rise in Business Intelligence tools to try to literally make sense of it all. This is leading to a number of changes in industrial engineering and business in general.

Business intelligence expertise is increasingly seen as essential to work in data analysis for manufacturing planning, demand planning and operational decision making.

If you’re going to work in consulting or analytics, job descriptions often ask the candidate to have experience with business intelligence or operation research tools if not both.

Engineers who work in sales or support regularly work with business intelligence experts, if they are not one themselves.

If you’re working as an analyst to improve business operations, you’re likely going to be expected to know how to design, write and publish reports through commonly used business intelligence tools like Cognos.

IT hasn’t entirely replaced time studies.  However, productivity experts regularly use business intelligence tools to study the productivity of different groups and review business operations.

Quality engineers are starting to be expected to know how to write queries of databases and business intelligence systems.

Business intelligence reports may provide leads on aspects to improve or document the changes that have taken place after process improvement projects.

In the case of CMMS and manufacturing systems where nearly everything is tracked by the Internet of Things, business intelligence tools may be how you get the information you need to do your job.

In summary, business analytics is focused on analysis while industrial engineering tends to be focused on improvements, but the distinction is starting to blur.

Quality Assurance vs Quality Control vs Testing

While the terms quality assurance and quality control are often used interchangeably, there are differences between the two disciplines. Likewise, quality control and testing are sometimes used interchangeably, though the terms are not exactly the same thing.


The Definitions

Quality assurance is a process designed to ensure a system meets its objectives. Quality assurance tries to design processes that deliver the consistent and correct results every time. It includes verifying processes already outlined are followed. QA tends to be pro-active. Per one Dilbert strip, QA involves telling people how to do their jobs so that they do it right.

Quality control refers to the activities to evaluate whether produced items and services meet standards. It tends to focus on defects in specific deliverables, checking performance or dimensions against pre-determined standards. QC is, by definition, reactive, because it finds imperfect products after the mistake is made.

Testing is the process of trying to find defects. Testing procedures need to be documented so that they are followed consistently by everyone who receives them. The test plans need to call out the right hardware, software and supporting information needed to follow the same test every time. And they need to be kept up to date as industry standards change, hardware evolves and the software behind many automated testing systems changes. Even things like where you store information on test results and test scripts need to be documented.


Quality Assurance vs Quality Control vs Testing in IT

QA in IT ensures your process is defined and appropriate. What is the scope of the project? Do we have a formal test plan? QA is the full software development lifecycle.

QC tries to identify defects in the product. The classic case is the database of bugs found during software testing.  One definition of QC was always executing the program, while QA may involve theoretical or administrative reviews. In the case of QC in IT, you have to run the software to find the ways it doesn’t deliver results appropriately, errors out, or literally locks up.

In IT, testing is running your software and hardware tests. And QC is specifically the software testing life cycle. Test plans should specific the IT architecture and hardware used for testing. After all, putting something on the wrong test bed is going to cause it to get very different errors than if the right one were used.


Does Automation in Software Testing Eliminate the Need for IEs in IT?

Quality automation engineers take it one step further and write the code that runs automated tests per various test cases and generates a report of defects.  However, you cannot assume this automation of testing is always accurate or complete.

In one instance, an engineer demonstrated his automated test script to replace manual testing that was going on, and we watched a number of error messages pop up. And because the script was only looking for errors like access control limit notices during the automated test, the dozens of popups generated weren’t recorded as errors by the script. And if the quality automation engineer isn’t clearly told what constitutes a success, you could get events like a report being generated counted as a pass when the report itself doesn’t show all the data or contains other errors.

In summary, no, automation doesn’t eliminate the need to apply quality assurance and quality control to any aspect of IT even if one can automate many tasks.

IE Lessons from Dr. Jordan Peterson’s Advice

While Dr. Jordan B. Peterson’s advice is widely applicable in a variety of areas, there are snippets that are particularly in line with industrial engineering principles.

  • Make at least one thing better every single place you go.

One way of describing the goal of industrial engineering is “better and better”. The definition of better itself is variable, whether you want it cheaper, faster, using less, or an improved design.


  • Tell the truth.

You cannot solve a problem if it is against the rules or culture to admit it in the first place. You cannot fix something if you aren’t allowed to share solutions or talk to those with the most knowledge about the issue.


  • Assume that the person you are listening to might know something you need to know. Listen to them hard enough so that they will share it with you.


One way to look at this is to give people your whole attention, because the little details and passing mentions may be the most important information … and it is what you’ll miss if you give them half your attention.

Another variation of this is how often people do surveys or solicit feedback only to skim over it, analyze it in aggregate and use intermediaries for what seems like the sake of efficiency.

Early in my career, a manager listened to my advice on solving a problem based on heavy theoretical reading. He replied, “If you want to find the solution, start with the people who are dealing with the problem.”

On one occasion, the seals were falling off a PCB board’s air ducts. I went down to the manufacturing shop, talked to a production head, and he put together a test of wash processes and adhesives on the seals. A line operator assembled the combinations of seals and adhesives on junk boards, we ran the lots through wash cycles, and we found the fatal combination. It took two hours. I returned to work in time for an engineering meeting, where I stood up to discuss the results. Most present had only started to consider how it might be testing. Asking the person with the most direct experience with the process resulted in an answer.

Many assemblers knew short term work-arounds that could be turned into permanent design solutions or had recommendations based on years of experience building, fixing and deconstructing the product. After several years in product development and production support, I was surprised to later find that many engineers were reluctant to talk to those on the shop floor … or even asked me to join in the meeting for my shop floor experience so they didn’t have to talk to the people doing the hard work.

  • Imagine who you could be, and then aim single-mindedly at that.

Burning platform, anyone?


  • Work as hard as you possibly can on at least one thing and see what happens.


Define progress for the moment – faster, leaner, simpler, more efficient. Then apply a fitting continuous process improvement methodology toward that goal. Re-evaluate and sustain the gain. Remember that you can shift the focus after you achieve a goal.


  • Nothing well done is insignificant.

Don’t denigrate small process improvement projects or modest gain in an area. We worship big projects, major wins, ignoring the fact that small, incremental progress can achieve the same or more and with less risk.

This same mentality is why politicians prefer big infrastructure projects over maintaining what’s already been built. Filling potholes and preventative maintenance aren’t as sexy as a new highway or overseeing a major equipment upgrade.


  • Remember that what you do not yet know is more important than what you already know.


It is the problems you don’t know about that are about to explode, hopefully not literally. It is the root causes you don’t realize are affecting your process that have the greatest impact on your quality.


  • Be precise in your speech.
  • Do not hide unwanted things in the fog.

I put these two together because of the tendency to use heavy jargon, whether it is in the hope of seeming more educated and thus justify one’s stance or in the misguided belief that if you rename something, the seriousness of it is reduced. The end result in both cases is confusion as to the issue involved unless you’re up to date on the jargon and often misunderstandings as to the severity of the issue. And sometimes people use the euphemisms and jargon fitting for a Dilbert comic to try to hide the severity of a problem.


  • Notice that opportunity lurks where responsibility has been abdicated.

Need ideas for a process improvement project? Look at the things others have given up on but really wish was solved.