Pouring a foundation for open innovation

This seems like a good time to post about corporate culture and it’s effect on product development initiatives (see here and here). So another won’t hurt.

If you’ve attended MRT and PDMA’s annual Open Innovation conference, you’re likely familiar with the standard drumbeat on the importance of culture change to successfully start using externally sourced ideas in product development.

Kevin Stark of NineSigma has recently published the following article in IndustryWeek: “10 Steps for Creating an Open-Innovation Culture“.

Why you fail at Lean Product Development

One of my favorite fortune cookie fortunes goes like this: “Many shall receive advice, but only the wise will profit by it.”   This is relevant to all corporate improvement initiatives and especially anything labeled “Lean.”

The biggest mistake that most make when implementing any big system changes, be it lean product development, six sigma or open innovation, is not sufficiently planning for the cultural impact.  These changes can be both physical and psychological.  The reason they are often under-considered is a simple one — it’s too hard to deal with and filled with risks.  But as we’ve experienced many times, it pays to sweat the soft stuff.

Many more companies are successful with lean manufacturing than they are with lean product development.  A lot of this happens for the same reasons, mostly having to do with staff buy-in.  If you have not convinced and sold the proposed procedural changes to those who must experience them, you will not go far.  Manufacturing has it a bit easier as shop floor personnel are more used to and inclined to cooperate if given precise direction whereas engineering, R&D, marketing, etc., are staffed by those trained to challenge ideas and scrutinize intellectual pursuits.

When trying to implement Lean Product Development, in general, people will focus on the technical issues first, such as how to reorganize work, and if trying to stick to a Toyota-type approach, how to adapt and implement shop floor tools such as a Haejunka box.  But tools are really the lowest hanging fruit of such pursuits.  If you have not changed your culture to be one where the tools are accepted and uniformly followed, then you are basically doomed.  And there are often A LOT of new tools to introduce.  It’s not enough to change how you do things, you have to also change how things are done, otherwise, after the honeymoon, things will quickly revert to the old methods.

Do Sweat the Soft Stuff

Last year* I was at a conference focused on technology and processes for global product development. In the hallway a representative from Lucent Technologies offered me his latest revelation:

“Ya know, sitting in all these presentations, it’s really clear to me what the problem is. It’s not network security or the limitations of current collaboration software…it’s the cultural issues. Every speaker has said that’s a problem. How do you get your people to embrace such big changes? You should do a conference on those issues.”

App-athy and the Value of Information

In the early to mid-nineties, I became enamored with the idea of lean information systems.  This was back when software applications were getting bloated and trying to be all things to all people but were unsatisfying to just about everyone. At the same time, enterprise applications were being set up to try to control all kinds of business processes in the name of cost control and efficiency. Multimillion dollar installations of enterprise systems employed countless consultants setting up, implementing and maintaining these applications that cast a generic set of industry specific best practices in the silicon equivalent of wet cement.

Lean manufacturing pundits mocked the wave of MRP/ERP implementations as a poor substitute for actually improving the flow and productivity of the manufacturing facility, while technology enthusiasts envisioned seamless integration across all business functions.

R&D Metrics: Should you punt on fourth down?

I play Fantasy Football every year and it is an entirely metrics-based pursuit.  If you’ve been under a rock, on Mars, with your fingers in your ears, you probably don’t know that fantasy sports take the statistical numbers from real players, teams and games and turn them into a composite score for fantasy team managers to compete against.  Maybe that doesn’t sound very sexy or fun, but it has become a billion+ dollar industry in the last several years.  It is HUGE.

Managers of product development have often fantasized about having the ability to manage ‘by the numbers’ similar to professional sports.  The allure is quite simple to understand, I mean, who wouldn’t want a binary system for decision making, if you end up wrong, you have your posterior fully covered by math.  Nobody questions the hard, cold logic of math, right?

But from experience, we know that math isn’t always a straight line, and that separated from human intuition, can often be dangerous.  Intuition is often mistaken for “guessing,” when in reality it is more like “subconscious logic” that taps into real data that your awake brain is not fully aware of.

In addition, humans faced with numbers often still need to interpret them, which puts a very inexact science on top of exact figures.  Back to football, a great example of this is Arkansas high school football coach, Kevin Kelly.  Coach Kelly is known for taking standard football conventions and standing them on their heads.  By his interpretation of the numbers, Coach Kelly never punts on fourth down and almost always attempts an onside kick after scoring a touchdown.  In one particular game, his team scored 29 points before his opponent ever got a possession.  Football purists may cringe, but it’s hard to dispute his results, after all, just look at his numbers!

MRT’s “Metrics” workshop addresses how to use the logic of measurement without losing sight of the end goals and ensuring that metrics never supersede the project vision, check it out:

R&D Metrics: Quantifying Portfolio Decisions, Projects and Profits with Instructor Wayne Mackey

Article: Down 29-0 before touching the ball

The Idiot’s Guide to Theory of Constraints (TOC) – Part II

At long last, here’s part II of our guide to TOC, in honor of the late Dr. Eliyahu Goldratt, originally published in The Critical Path email newsletter on February 29, 2000.

Did you miss Part I?  Click here.

In Part I, we focused on the basic root philosophy behind TOC to provide a jump-point for those interested in learning more. In part two of our guide, we list the major relevant books and provide a very brief glossary of TOC terms.

THE BOOKS

THE GOAL – this is the book that started it all. It’s written as a “business novel” – a true innovation for its time. The protagonist is Alex Rogo, general manager of a Unico plant about to go under, along with his career. Interspersed between a side plot about Alex’s family life and spousal relationship, Alex learns from Jonah, his former physicist professor and now a high-priced consultant, about how to save his job and business. By rethinking the flawed assumptions of how a plant should be measured and operated, he saves his business employing non-traditional TOC techniques “under the radar” from his corporate overseers who would no doubt stop all that money-making nonsense if they knew about it. The Jonah character, one could suppose, is the alter ego of the book’s author, Eli Goldratt. Newer editions include the appendix “My Saga”, which explains the true origins of TOC. Many readers have expressed the similarity they find in Alex’s life and their own. 

Lean vs TOC: Reader Reactions

The following “Reader Reactions” were originally published in The Critical Path email newsletter, December 15, 1998.  Below is the large amount of reader feedback we got from our “Lean vs TOC” piece.  To read the original article, click here.

Some of the letters below are followed by our comments in bold.

Dear Critical Path:

How would Taiichi Ohno feel about this?

I think Ohno would ask, “Does your output now match your customers requirements?” From a personnel response your example of 30 outside people is not typical of a TPS kaizen event. And so, from this atypical example a good point could be made by anyone… Goldratt could have chosen a more honest comparison. His point of focusing on bottleneck “Herbies” vs TPS Lean focusing on the value stream could have been made with a more honorable example.

As for comparing the two projects: What were the two projects?

The TPS project could be where they are trying to take out another person by improving the processes within a multi operation cell after a succession of previously successful improvement events. As compared to the TOC project where the team was looking at a high scrap, high labor, high overtime, high backlog, very problematic area with much more opportunity for improvement than the TPS project.

Or, in other words the TOC project had a lot of “low hanging fruit” as compared with the TPS project reaching high for their improvement. Maybe the TPS project was breaking paradigms while the TOC project was solving problems.

In conclusion, to imply that Toyota is not concerned with bottlenecks is false. They are, they just call it takt time. I for one like what both the TOC and the TPS systems have to offer and will use both ways of thinking to promote improvements.

Sincerely,

Bob Schroer
Wizard of WOW
Hi-Stat Manufacturing

Exceptional Management

This article was originally published in The Critical Path email newsletter, March 21, 2003.  

Not all products are the same. Not all development teams are the same. Why then do companies try to create standardized development processes? Logically, any company attempting this does so to alleviate perceived problems with recurring errors, things like rework, slow cycle times and information defects. The theory is that a formulaic approach will drive down process variability with benefits similar to how a standard tooling process will drive down defects and scrap in manufacturing. Unfortunately, this is not without its costs.

Lean VS. TOC

This article was originally published in The Critical Path email newsletter, December 15, 1998.  We received several emails about this article when it was published which may be even more interesting than the original piece.

LEAN VS. TOC – GOLDRATT’S PERSPECTIVE

At Management Roundtable’s recent Metrics conference, I had the opportunity to participate in a special luncheon with Theory of Constraints guru, Dr. Eliyahu Goldratt. Having read both “The Goal” and “Lean Thinking,” I took the opportunity to ask Dr. Goldratt a question that I had been thinking about for some time:

“Dr. Goldratt,” I asked, “Can you compare and contrast TOC with Jim Womack’s “Lean Thinking” as it’s derived from the Toyota Production System?” Both philosophy ‘systems’ appear cast from the same mold, both are strategies that focus on value, both challenge ‘batch and queue’ conventional wisdom, and both are attempting to apply their shop floor principles to the overall enterprise, especially product development.

The Idiot’s Guide to Theory of Constraints (TOC) – Part I

The late Dr. Eliyahu M. Goldratt was a genius, a visionary, an unbelievably prolific business guru…and a scary man.

Sadly, he passed away this past June of 2011, and I don’t mean to call him scary out of disrespect, honestly, it was a trait I think made him more effective.  He was exceptionally intimidating despite a short stature and seemed to always get his way, I mean, look at that mug, would you contradict this man?  He once opened a keynote speech by saying, “business consulting is just a hobby of mine, my real occupation is as a soldier, my real job is to kill people.”  No joke.