Manual Manufacturing Work

Manual Manufacturing and Assembly

We take time to ensure the product is able to be built consistently.  We do our best to make the manual work as infrequent as possible and where we are unable to eliminate manual work, we design the product in ways to ensure a repeatable and reliable outcome from the work.   For example, we need an LED to have a certain defined distance from the printed circuit board to allow the LED to protrude just right through the enclosure lid.  To get that defined stand off, we use…a……standoff.  The problem comes when that effort does not produce the results we wish.

Error in Manufacturing

In this case the first production run produces the product with this installed spacer in the desired way that meets the fit needs. The problem comes when the next batch is run on the manufacturing line. The errors that came from the first batch production run, were not found in the … Continue reading

Manchester TQM for Project Management

I recently had a phone call from the acquisition editor at Taylor and Francis, John Wyzalek.  He informed me that a book we wrote a couple of years back (Total Quality Management for Project Management), is being used at Manchester Metropolitan University, and gave me the contact information of the lady creating and teaching the class, Maria.  I have had a few calls with Maria Kapsali since then that have been very interesting.

We discussed how the Total Quality Management tools can help us avoid deluding ourselves.  However, at least equally important if not more so, is having a team come to some common understanding of what is being witnessed.  The discussion pointed us to how to evoke ideas of the source of some of the issues being witnessed.  For example, we explored starting with the brainstorming tool often associated with Total Quality Management, the Ishikawa Diagram or fishbone diagram.  The students had a project associated … Continue reading

Project Success & the Metaphorical Triangle

Project Success & the Metaphorical Triangle By Steven G. Lauck & Jon M. Quigley, MS PMP CTFL

Project Success – Project Success – Project Success! That is the hope of any organization when hiring and assigning the correct project manager to each project. For me, Project Success has always come down to fulfillment of Scope, Time, Cost, and Quality.

Project Managers must understand that there is a give & take or push/pull on the constraints in the shape of a triangle. Once the project is in motion any force pressed on the metaphorical triangle influences the sides and internal shape of the triangle.

For example, an accelerated schedule. The acceleration will require additional resources – costs, time, and resources. Or consider when a stakeholder or sponsor submits a change request. The resources to analyze the change request are resources that are likely taken away from executing the already agreed upon project work. Initiating the change management process adds … Continue reading

Regression Testing

By Jon M. Quigley

I saw a LinkedIn post yesterday about scope of testing during times of compressed schedule. The position was to test what is new in the software, and of that new, what is the most important, perhaps meaning what if it goes wrong, would be the worst for the client or customer.  Generally this is probably a good idea. However, there are some drawbacks to this approach.  This means no regression testing. Regression testing is testing of the old software features when we add new software features to the product.

Testing as above, is predicated on the belief that those things that we have changed or added, have no implication or impact on those features and functions that were already in place prior to this last iteration of the software. That may not be true.  If we make changes to some software module that is used by other functions, we may miss testing a change in a … Continue reading

Common Cause and Special Cause Variation

Variation!

Though sometimes we may refuse to recognize it, the world is a full of variation, even in the things we think or believe are constant. For example, my wife has been known to say, “you always do…” or “you never do…”, to which I retort, I am human and I am not that repeatable.  I say that, but it is not just humans that are not so repeatable.  Everything has variation, and understanding this variation, is important for product development, project management, manufacturing, product testing and so much more.  To master this work, we need to understand this variation as completely as possible.

Common and Special Cause Variation

Shewart is credited for developing the concepts of special and common cause [1].  Special cause variation, are variations that are outside of the expected (intermittent) range of possibilities. Common cause variation, are the variation expected, we know about these, these are predictable, provided we have put some effort into learning about … Continue reading

Poke Yoke

Poke Yoke

Jon M Quigley

There are a set of tools and techniques that come with developing products for the automotive industry and are part of the Advanced Product Quality Planning for the product.  We have written about APQP or some years and have decades of experience in this approach to product development.  In general, the phases of the project are described as:

Voice of Customer Product Development Process Development Product Validation Process Validation Launch Feedback

 

 

We have a discussion board that supports questions you may have regarding APQP.  Today, we will ruminate on the technique known as Poke Yoke, which I heard an Supplier Quality Assurance professional refer to as “goof proofing”.  While largely benefiting manufacturing, these considerations and implementation is achieved in the development work, otherwise we end up doing considerable rework of the developed product to optimize manufacturing or field service work. Rather, we will use design for manufacturing (DFM) or design for manufacturing … Continue reading

Missing Requirements

Missing Requirements

Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray.

Wearing Many Hats

I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company.  This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.

Product Development Input

The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains.  However, the marketing person was essentially a customer advocate and not really an engineer.  In … Continue reading

Why formalize root cause analysis?

Why formalize root cause analysis?

 

There are many approaches to determining the root of our problems.  In the automotive world, there are two typical approaches, the 8D or the 8 Discipline, or the A3 (named for the paper size).  We will not go into the details of either of these approaches but you can find the templates for these by clicking the links above.

There are some benefits to a formalized root cause analysis.  We can think of 6 reasons as listed below:

Controls jumping to conclusions and just working on the symptom Repeatable Coordinates effort / focus Documents actions so we know what have tried and what is next Traceable for future events

 

 

Controls jumping to conclusions and just working on the symptom

A formalized approach to root cause analysis in such a way that will keep us from jumping to conclusions about the nature of the failure.   Those that have read this blog for … Continue reading

Independent Test and Verification

Independent Test and Verification

We are composing a glossary of testing terms and we take one from that work today and discuss here.   We welcome any and all that would like to contribute.

Today we discuss development and independent test and verification.  A development organization can be structured in many ways. The development and testing can be essentially one department under one management structure, or these two areas, development and testing can be separated each with a respective hierarchy.  Like most things, there are benefits and drawbacks for each approach.  The trick is to map the biggest benefit to your organization, or reduce the negative effects on your organization.  All of this means the selection for organizational structure is likely not best left to an arbitrary decision.

Communication

I am sure we see the obvious benefit of having the test personnel integrated with the development staff.  Those who have been in development for awhile no doubt understand the communications … Continue reading

Task Dependencies and Probability

Flip a coin, heads or tails. The probability that it will come up heads is 50%, after all there are only two sides.  Flip that same coin again, the same probability, 50%.  However, if we say that success is two successive heads (or tails) that is different. The probability of two consecutive heads, is the product of the two coin tosses (50% x 50%) or 25%.

I’m sure we understand task dependencies.  This is fundamental to project management and schedule.  Dependencies are the connections between tasks for example, I must put socks on before I put my shoes on (assuming I wear socks, which I generally do).  Of course, this is not the only type of dependency (finish-start). There are four actually;

Finish-start Start-start Start-finish Finish-finish

 

 

Let us focus on finish-start for a bit. Specifically, lets talk about a portion of the resulting schedule and the task consequences on the entire project.

Each task has … Continue reading

Subscribe to our Newsletter

Subscribe to our Newsletter
Name
Email *
Single Sign On provided by vBSSO