Daily Archives: June 2, 2010

More Headlines You Hate To See

Editor’s Note: Today’s post is from Dick Locke, Sourcing Innovation’s resident expert on International Sourcing and Procurement. (His previous guest posts are still archived.)

Your supplier’s employees are committing suicide. News articles are showing up mentioning your company’s name as a major customer. Your actions are being tracked carefully. (Apple and Dell investigate Foxconn plant)

Headlines like: Foxconn Makes Employees Promise Not to Kill Themselves, Plenty of Foxconn shame to go around, and Foxconn suicides: capitalism and Marxism treat men like animals cover articles that name Apple, HP, Nokia and Dell as key customers. The term fair trade electronics gets increased currency.

What went wrong here? It would be professional malpractice to even venture a guess without talking to any of the principals involved. Instead I’ll write about electronic industry practice and ask a question or two.

The electronic industry has an Electronic Industry Code of Conduct that major buyers require suppliers to agree to follow. You can download a copy from the EICC site. You can also see the logos of their members, which include Foxconn. It looks like a good specification to me. It covers the key issues of employee relations and environmental responsibility and requires that signers require at least their first level suppliers to comply.

Of course, a key question is whether Foxconn actually complies or just agreed to comply. I don’t think anyone not directly involved can answer that.

So here are my questions:

  1. What do others think of the EICC specification?
  2. And do other industries have similar, cooperatively developed codes of conduct (on a global scale)?

Let’s get some discussion going.

Dick Locke, Global Procurement Group.

Share This on Linked In

What About Risk-Based Development?

I enjoyed this recent article over on Industry Week that identified the need for new development processes that will make product development faster, less expensive, and more successful in its outcomes and that covered agile development, knowledge-based development, and spiral development processes as potential processes a company could use to improve product development and associated outcomes. But it made me think about the alternatives not mentioned — namely risk-based development. But first, let’s discuss why new development methodologies are needed.

As noted in the article, a 2008 survey showed that companies met their product launch dates only 45% of the time. Furthermore, a recent survey by Boston Consulting found that only 52% of senior executives were satisfied with their companies’ innovation ROI. That’s clearly a fail. NPD is hard, and not every project will succeed, but these results are equivalent to saying that management is okay with failing half of the time. That’s not acceptable.

However, according to the article, besides making sure that there is a formally defined (and followed) process in place, the only way to see significant improvement is to identify the “next big thing” — the idea, invention, or improvement that will make the product development process faster, less expensive, and more successful. And while I don’t necessarily agree that it has to be “big”, I do agree that, in most cases, improvement is needed. But what kind?

According to the article, the leading contenders are agile development, knowledge-based development, and spiral development processes. Agile development, which started in software, mandates incremental development by teams in short time frames, such as one to four weeks. The frequent inspection and adaption is designed to allow changes to be introduced quickly, and before doing so would be prohibitively expensive. Spiral development, which also started in software, mandates multiple iterations of the entire process, improving and expanding the product in each iteration. For example, in new cell phone development, spiral one would be the base hardware and core OS, spiral two would include the camera and motion centre and API for core apps, etc. Knowledge-based development focusses on the creation of reusable knowledge through learning cycles that use set-based design. Multiple options are created and then refined and eliminated until the winning design is found.

They are all great processes, and they call confer advantages above and beyond the traditional staged development usually employed by manufacturers, but they all miss the point. If the reasons for failure are analyzed, it will quickly become clear that the primary reason most NPD projects miss their deadlines, or outright fail, is because something didn’t go according to plan — a disruption occurred. A risk, known or unknown, materialized and set everything back.

This seems to indicate that what we really need is risk-based development. In risk-based development, after identifying a feature/function list and a few potential high-level designs, the first thing the team would do would be to identify what new innovations are needed to succeed. The team would then rank the innovations on a scale from 1, or incremental renovation of existing technology, to 10, revolutionary invention so that the innovations with the highest score carry the highest risk. Then, the team would attack the highest risk innovations first in a multi-round/multi-stage development process. If the highest risk innovation could not be solved, the project would be suspended until a new idea was identified or terminated if the cost/reward ratio to solve the risk was determined to be too high. This would prevent the situation where the product is taken to 90% completion only to find out that the “killer-app” feature can’t be completed, which makes the product worthless and costs the company millions of dollars and dozens (or hundreds or even thousands) of man years. And this development methodology would work with any stage-based or phase-based process that is already being utilized by the company. It just makes sense.

Share This on Linked In