Archive for December, 2012

Off Topic

Posted on: December 29th, 2012 by admin No Comments

As you may have noticed, we are working on a Configuration and Change Management book. In an effort to articulate the proposition, we are using the blog temporarily to define what we seek and the benefits to those who contribute.

We are looking for configuration management tools, techniques and stories. We are especially interested in what we refer to as war stories or failure stories. We believe these are great from which to learn

  • Software perspective
  • Manufacturing perspective
  • Supplier / Customer perspective
  • Embedded product perspective

In return for these contributions, we will make sure your name appears in the front matter of the text. Additionally, we will gather the names of these contributors and have a drawing to give away five production books.

Please use the contact us page (http://www.valuetransform.com/contact-us) to submit your contribution. We will have your email address for the subsequent book raffle and any questions we may have regarding your contribution.

We welcome the opportunity to collaborate with all of you talented people out there!

Jon

Planning Prototype Parts

Posted on: December 19th, 2012 by admin 2 Comments

by: Wally Stegall and Jon M Quigley

The reason for prototypes parts is to learn something about the product before we spend larger amounts of money on the future product development. We want to know things that are not readily knowable by our immediate engineering work. The longer it takes us to learn, the longer our project and product are at risk and the later we deliver. Elimination of prototype critique without some other suitable substitute (such as modeling) is equally poor. Understanding and measuring of key attributes or critical characteristics is essential, and is the entire point of the prototype. Accomplishing this critique quickly requires:
1. Identify objectives of the prototype (questions requiring answers)
2. Identify key personnel
3. Identify activities (tests and product critiques)
4. Planning of those activities
a. Prioritization of the activities
b. Map human talent to activities
c. Sequencing of the activities
5. Monitor and follow up

Based on the critical characteristics and a frank assessment of what is known and unknown (and needs to be known) an outline of actions and test can be defined to fill in the knowledge gaps. This will be the objectives we wish to achieve with this prototype part.

The prototype review requires a dynamic technical interaction across the span of the development groups involved. To be effective, we require key individuals from teams, spanning from the concept, sub systems, hardware, software, product, and end user. This sounds simple right. Not really, considerable amounts of money and time are lost every day to the vacuum of responsibility. The activities planned may require the prototype to be broken down into sub-assemblies before going to the final prototype. With planning comes reserving time and resources. The core team planning the program must allocate the time and resources required for the test and analysis prior to the prototype availability. We must include in this planning where any potentially destructive tests may occur. We want to learn all we can about the function and performance before we schedule the tests that may evoke a failure. This is especially valid when few prototypes are available.

Once the prototype has been delivered, we must monitor who is conducting what test. We must remain aware of dependencies in the use of the part. For example: Tom cannot start until Angie has completed her critique. In this case the dependency is due to material availability and not some technical or project need. If we run out of time, Tom’s review of the prototype may suffer, and we may not learn what we need and our product is at some risk.

If you think is project management – you are largely correct, and that is where we can see things fall apart. Failure to define and follow steps similar to those above waste money and does not reduce risk. To allow a next phase release without resolving the identified critical items and performance issues is professional negligence, but we will talk more about that in a later blog.

The Case for Modular Design.

Posted on: December 10th, 2012 by admin No Comments

by Jon M Quigley
I sit in awe at the variety of things that can be built with Lego. One is bound only by one’s imagination. However the wonders of modularity are much more than kids play and business and engineering can learn considerable from these ideas.

Even before I was playing Lego’s with my son, I was an embedded engineer for a company that developed industrial process control products. I worked there with Rick Byrum (founder of Raptor Performance). The experience allowed me to work with both hardware and the assembly code, mostly Intel and Microchip products of microcontrollers and the obligatory 7400 series accessory chips. The company we worked for was rather small. Their product offering was customized to meet a variety of manufacturing demands. It seemed as if every day a new variant for the product would be required. Working with Rick, we set about a plan that would allow one core set of hardware and embedded software to be used to meet this wide variation in product permutation and expectations. The product had one enclosure, with one operator interface, however, the inside would be populated with electronics and software defined by the customer demands. Portions of the printed circuit board were populated depending upon the customer order and the same was true for the software, parameters were adjusted to enable features. That included analog outputs controlling switch mode power supplies. We found considerable savings in self-imposed “standards” that made adapting the product further much easier. Additionally, the reuse of tried and demonstrated hardware and software reduced the risk to future product iterations. In an earlier model (prior to the convergence on one base design) we found a particular input transient that would generate a latch-up condition. This learning on the way was used in the convergence reducing this risk of occurrence to all incarnations of the product rather than managing this change across a variety of hardware and software platforms.

Using common parts and subassemblies reduces lead times and risks to the larger project. For example, consider the reuse of the power supply section for a product that will be exposed to a similar set of stresses as the present product. The power supply for a microcontroller family will have a similar set of performance requirements such as:
• allowable ripple voltage content
• maximum operating voltage
• minimum operating voltage

A product that has been out in the field and in known applications provides us with first-hand knowledge (via our customers) on how the product is used and performs. With a core platform we learn from one product that can improve the modules of other products using that module. Essentially we are constantly learning and improving all of our product quality from these interactions. Specifically, we are talking about warranty costs, as well as return and service information. In a single core design we are more readily able to make one set of adjustments to a variety of our products.

Recycling or reusing parts of the design shorten the product development cycle and minimize the impact upon manufacturing including the material handling (storage of parts). Additionally, the deficiencies found in one product (sub assembly or module) can now be corrected and easily considered for application in the other product incarnations. In other words, we update our other products to include this change improving those products quality along the way also.

Value our employees!

Posted on: December 3rd, 2012 by admin 1 Comment

Jon M. Quigley

I keep ruminating on the article from the American Management Association on people leaving their previous employer (http://www.amanet.org/training/articles/How-Employers-Drive-Away-their-Employees.aspx?pcode=XCR).

The findings of Leigh Branham in the above study are both discouraging and encouraging. Discouraging in that there is a problem with how we treat our people. Encouraging in the hope maybe we will do something about it.

As the old adage goes, as you sow, so shall you reap. It should be obvious that you get the best out of people when you give your best to them. This philosophy is part of a consistent trusting relationship. So what happens when the trust is violated in the ways enumerated in the linked article or in other ways? Why is it we do not appreciate the employees we have until they come to us with another job offer? Consider this everyday story.

An employee has a position at a company. This employee has consistently delivered for the company over many years, cost improvements, quality improvements and timely project deliveries. The company rewards this person for their performance with less than Cost of Living Adjustments annually. At some point the employee takes other jobs or interviews at other companies in search of a way to advance. Another company, which has no track record with this individual, hires the person based upon resume and an interview. This new company is taking a risk as they have no real (historical and objective) knowledge of the individual. Additionally, the new employer oft times is offering more money than the present salary the prospective employee is making to take the position. The employee comes back to their soon to be former employer, and lets them know they have a job offer at another company providing the present employer with requisite two-week notice. Now, all of a sudden, that employee’s value at the present employer goes up! We want to improve their salary, or work hours or scope of work, or even all of the above. What has happened that now this employee’s value increased from the last few weeks, minutes or even seconds? Assuming they did not acquire a new certification, degree or other skill, nothing has changed in the seconds from when the employee did not have another offer to the time when they are wooed by another company, accepted an offer and are delivering their notice. Do we only value our employees when they have found another company that is willing to take on the uncertainty of the new hire, and put more money and career improvements on the line?

I have seen many articles and training on making sure we bring the best talent we can into our organizations. The statement could be better worded, do the best you can to keep those in your organization that perform. The value of an employee should not rise because in the last 30 seconds because somebody else recognizes what you are in fact taking for granted. When you make the counter offer you are essentially saying, “We know we have treated you unfairly in the past regarding compensation (or whatever deficit).” This is essentially a fairness or trust issue. We are uninterested in your wellbeing unless it impacts our wellbeing (the key employee leaving the company.) This does not reflect a trusting relationship.

Single Sign On provided by vBSSO