Change Management ⇔ Good Management

Change management is a dreaded assignment in many companies. It is not leading edge and is normally associated with what a newbie would be asked to do when they joined the company. Those working on new products work hard to avoid any type of sustaining responsibility, which is viewed as a cleanup job to be handled by the less talented.

The company culture that lets this attitude prevail is one that will operate at a less than optimal or productive level, reduced profitability with substandard product quality and customers that question why they purchase their products. Employees at all levels recognize the problems producing products in this environment. What do they see?

• Engineering documentation that is red lined or out of date requiring knowledgeable individuals to recall how it was last built.
• Bills of material that are incomplete resulting in shortages of parts actually needed to build the product and the accumulations of obsolete material that is no longer needed. This material may ultimately be scrapped signaling to everyone that waste is acceptable.
• Products that do not perform as they used to due to variations in incoming material quality or vendor production processes.
• Delivery schedules that cannot be met on time due to material shortages and quality issues.
• Product cost that is above standard because of excessive material cost expediting material in small quantities and excessive labor cost in overtime assembling and testing products to expedite delivery
• Employee morale suffers because no one seems to care that the job is done right, or that things are done and ready when they are supposed to be, or that the product is not built in a quality environment.

A quality change management process is the foundation of an excellent company. Having products that have sizzle is certainly valuable but sizzle will not carry the day unless the product can be produced consistently at a high level of quality with predictable cost and delivery. What are the key steps to do this correctly?

• All parts of the organization devote and invest in change management for existing and aging products just as they would for the next best thing coming out of product development.
• Phase-out and phase-in of design changes are PLANNED and SCHEDULED reducing and possibly eliminating excess unwanted material, documentation is reviewed and walked through manufacturing and test as the new change takes over to make sure all stations in the process are communicated with and changes or exceptions are incorporated back into the engineering package.
• Discoveries of weak design points are addressed and dealt with to eliminate the risk of future failures.
• Purchasing and incoming inspection make sure that the quality and reliability of incoming material is high, changing vendors that cannot consistently deliver quality components on time that meet cost objectives.
• Employee morale is high due to the company wide attitude toward doing things right for all products – and not just for new products.

Examine the balance of commitment in your company. Is the “back office” just as committed (and resourced) as the “front office”? Don’t let your organization side slip toward the highly visible functions (product development, sales, etc.) and starve the fundamentals of your business model. Listen and look for the signals – cost, quality, schedule, customer complaints - that indicates that this is happening.

Good change management is good management!

New Product Introduction (NPI): What is your target?

Businesses commit high-valued resources (people, cash and windows of opportunity) to develop and introduce new products to market. Unfortunately, in many cases, product development is well along before attention is applied to whether the NPI process is appropriate for the product and the targeted market. This is particularly true of products where the product definition was developed without broad based customer involvement known as the "Voice of the Customer (VOC)".

By not engaging sufficient customer or "market" input the NPI process is starved of critical information that is needed to determine what "acceptance" criteria the product will have to satisfy to be a success. This can be a critical problem for a company that has traditionally designed and developed products to an acceptance criteria defined by a narrow (often just one) set of customers and then decide to convert an existing product or technology for use in a larger market. The normal NPI process used for this new endeavor will fall short of what is needed. It needs to reflect the condition that many customers will determine the success of the product and not just a few or one.

In every case the NPI needs to recognize the unique constraints of the market (customer community) that the product is intended to serve - one customer or many. An NPI process designed to successfully guide development of a product to meet or exceed customer acceptance criteria is radically different than one that will need to measured by market acceptance. The precision of the effort to determine market acceptance into a design criteria by an anonymous customer is a critical and challenging task. The customers voice has to be represented (and defended) in the same way that a detail specification in a customer acceptance criteria is adhered to in order to deliver the product. Internal resistance to accepting external acceptance factors needs to be dealt with effectively or the success of the product will be compromised.

An extreme example of this problem involved a team of extremely talented engineers developing a software tool for a market unfamiliar to anyone on the development team. Developing the product was looked upon as solving a difficult problem. When the product was released the response was far short of what was expected.

I was asked to look into why the product was struggling and discovered that the product specifications were developed without any involvement from any users. I scheduled several meetings with "typical" customers and the feedback was valuable - but too late to save the product. The product did do what it was designed to do, it solved a critical problem, it was recognized by customers as a technical achievement but it did not integrate with the work flow of the user so that they could view it as an inline productive tool. The end result was that the product was withdrawn and the team dissolved.

Could this have been averted? Yes! Surveying customers ahead of time to determine how they would use such a tool would have revealed the critical work flow integration requirement that may have resulted in a successful product or possibly a decision to go in a different direction.

The moral to the story. Know your target audience. Make sure they are represented throughout the NPI process. Invest in a sold NPI process or spend more time (and money) later trying to get the product right, in front of the customer, once it is in the market.

Product Customization - Boom or Bust

A challenge that many companies (small & large) wrestle with is the issue of product customization outside of the standard features that allow some form of user customization at order configuration. This often requires an investment in engineering, new documentation, quoting an engineering change charge and/or new product price and tailoring the manufacturing/build/test cycle to deliver a quality product - on time.

Why is this a difficult question? Sales rushes in with an order from a valued or targeted customer to buy the standard product except for . . . In the desire to either keep the customer, add a new customer or (more probable) meet sales objectives the order is accepted. The question is whether your order process is designed to operate effectively in this mode.

• Is the sales process sufficiently capable of capturing the necessary specifications without committing an engineer to an onsite meeting with the customer?
• Do you have engineering change staff (often called sustaining engineering) or will you need to siphon off valuable engineering time from engineers who are committed and personally invested in the design of new products?
• Do you have a production build group that has the flexibility to efficiently do "one of" builds?
• Is your accounting process setup to accurately collect the cost of this type of business so that you know where your profit (or loss) is occurring separate from your normal production business?

The answers to these questions are not good if customized products are not the focus of your business model. Too often the end result is business that you wished you had not taken or "bought" which is more likely the case. The goodwill with a valued customer is put at risk, the future with a new customer is questionable, and your profit margin is unknown if the customized product does not have the same product quality and performance your standard products have.

More significantly is the lost opportunity of the organization to keep valuable (and hard to find) strategic resources applied to the future of the business. One hour (you wish it would be just one hour) of engineering time redirected to a "one of" customized project is not just one hour out of the day as it is difficult to get back into the flow with where the project was let alone the impact on engineering morale when they are used for a project like this.

Consequently the promised upfront gains of an organization redirecting their business model to take on a customization project are not met. A common result of this decision is:

• profits performance is compromised,
• customer relationships are strained, and
• strategic direction for the future of the business is put into limbo.

The answer? Stay the course and do what you do well and avoid the temptation to be a marketplace super hero!

Get the Facts!

Our new innovative product on the new 747-400 was experiencing a high failure rate during installation. Boeing engineering pointed the finger back to us as producing a failure prone product. However, due to our recent adoption of SPC tools and processes the failure modes were not indicative of a manufacturing related defect or failure.

Boeing was new to the SPC process and even though they were dictating that many of their suppliers adopt it they put aside our SPC evidence and remained firm in their belief with non-SPC data as their basis. We made repeated requests for Boeing engineering to go out onto the assembly line and talk to the installers to get a first hand understanding of we configuration in which the units were failing. These requests went nowhere and were denied. They were hesitant to do their own due diligence and have engineering talk the installers to get further details – a classic engineering/manufacturing silo effect.

Coincidentally British Aerospace was also putting our product, same design different package, on their new regional commuter jet the BAE 146. I made a courtesy visit to their factory and they greeted me with the news of our product “failing on the line”. I took the opportunity to ask if I could go into an aircraft where the product was installed and talk to the installation team. They immediately complied in an interest to get to the bottom of the problem.

While I did not have any detail failure analysis of these units I suspected that the failures they were having were of the same order as those at Boeing. I was escorted into a selected aircraft that was in the stage of assembly where our product was installed. I was introduced to the supervisor who quickly confirmed that the units were failing at a high rate. I asked to talk to the actual person who installed the units. He was nearby and said that yes, the units were failing but that was not the whole story. When the installed unit failed he would install a second unit and if it failed he then tested the wiring harness and almost in every instance he discovered a short in the wiring harness that was damaging our product. Our product was in fact testing their wiring harness to see if it was defective or not – an expensive proposition.

I asked if the wiring harnesses were high pot tested and they did not know. The engineering manager that I was with took me over to the wiring assembly area where the harnesses were assembled on large tables. The supervisor there said that at that time the harnesses were not high pot tested but they had a request into management to purchase the test adapters and equipment for the test but it had not been approved.

I returned to Seattle and immediately called for a meeting with Boeing where I presented my findings from my visit to British Aerospace. They were somewhat skeptical that what happened at BAE would occur at Boeing. I requested that they provide evidence that the 747-400 harnesses were high pot tested. A week late Boeing engineering reported that in fact the cause of the failures of our product was resolved. An immediate change had been made in their wiring harness process to high pot test them before they were put on the aircraft. Boeing accepted responsibility for all of the return units the “failed” and further failures dropped to a near zero level.

When failure modes don’t add up, trace the problem to its root cause and understand the failure environment. Go to the source and “get the facts” to make sure you are getting the real story. Too often organizational barriers filter information which is further distorted as it is passed through multiple people on its way to you and even within your company. It is amazing how quickly problems can be solved when you have the complete information.

Get the facts!