An IPT, or Integrated Product Team, is one of the most potent tools in the Lean Engineering toolbox. It involves gathering representatives from all stakeholder organizations to form a team, declaring a value statement (or goal), a rating system, and a set of criteria to rate each idea. The next step is to brainstorm for solutions - where all ideas are included and no idea is a bad idea, not yet anyway. Then, the team systematically rates each idea in each of the agreed upon set of criteria. The winning solution should emerge at the end of the exercise. Now I know what you are thinking: easy for you to say...
So rather than filling pages of explanations and methodologies, I will highlight some pitfalls and some observations I gathered over the years. If you find yourself guilty of one or more of these, you're probably not doing it right.
1. It's taking too long.
The purpose of an IPT is to arrive to a solution for an open ended problem, not to actually execute the solution. I am amazed when people tell me they've been on IPT "X" for 2 years. You have got to be kidding me. The IPT should be sequestered and narrow down the various concepts to produce the winning solution in days, 1 to 2 weeks maximum. Then the solution should be delegated to the design groups and the team disbanded. Being a member of an IPT (or several as I will discuss later) is not a career path. Here's a hint you're doing it wrong: the solution produced by the multiyear IPT looks and feels like all the past solutions, except that it's taking longer and costing you more.
2. Hooray for me; I'm on seven IPT's.
You wake up one morning, come to work and everything is being done by one IPT or another. Your boss tells you that starting today you are on yet another IPT, making it your 4th or 5th. Your life has disintegrated into an endless series of IPT meetings (with pre-meeting prep and post-meeting action items) and your productivity is quickly approaching zero. Stop. You're doing it wrong. What you've done is created many "mini" design groups and have circumvented your first and second level managers, making their role nebulous at best and their life quite hard. For no good reason. Not everything in life merits an IPT. The good old-fashioned design groups are great. Use them for everyday production matters and only employ an IPT when it is needed. Again, large, critical, open ended problems merit an IPT. That's it.
3. My IPT lead told me to...
One of the clearest signs that you're doing it wrong is if you use IPT leads. Presumably to tell team "members" what to do and when. Congratulations, you just filled your organization with first level managers without any training, mandates, or accountability, and your organization is quickly screeching to a halt. Another sign: you now employ 10 times the people you used to employ 20 years ago and still working on basically the same number of products. You're doing it wrong. An IPT must have a facilitator, more of an educator, preferably skilled in lean tools and methodology. He guides the discussion and keeps everyone on the same page. He is not a lead. The risk of having a lead is that you must pick one lead from one group. Guess what the bias of your IPT (and I use the term loosely here) will be? Yep.
Well, there are many more signs, but those should get you started.