Dedicated Product Teams
It often makes sense to organize into sub-groups, each of which focuses on one specific product line.
These sub-groups form what is sometimes called a focused factory.
Everything is rearranged so that Dedicated Product Teams are like "factories within factories".
To the greatest extent possible (though usually with some exceptions), each Dedicated Product Team has its own:
- Work cells or production lines — ideally containing every piece of equipment needed to manufacture the product
- Support teams — such as design engineering, manufacturing engineering, quality, sales, marketing, etc.
And (if the noise issue can be resolved) the support teams are ideally relocated onto the factory floor — so that everyone can be very near each other to form a very targeted and highly communicative team.
What's the difference between
a Dedicated Product Team and a Concurrent Development Team?
The Dedicated Product Team exists for the entire life of the product line.
The Concurrent Development Team focuses only on the development cycle.
Often, the Concurrent Development Team is a sub-team within the Dedicated Product Team.
As contrasted with a typical sequential development process,
the formation of dedicated Concurrent Development Teams
has routinely proven to reduce development cycle times by 50%.
What's a Concurrent Development Team?
A team consisting of everyone needed to develop a product line.
(e.g. design engineer, manufacturing engineer, tool engineer, product engineer, marketing/sales rep, buyer, someone from the plant that will have to actually make this thing, etc.)
Their shared objective is to perform Quality Functional Deployment for a single product line.
Team members' desks are usually relocated so that team members sit close to each other.
If it is a big project, many of these people will have no other responsibilities. They will not be assigned to conflicting priorities every Monday morning.
The entire team reviews and approves each other's completed assignments as the project moves quickly to completion — thereby eliminating...
of serial “throw-it-over-the-wall” development processes
- Redesign because someone brought late into the process identifies a design flaw that wasn't taken into consideration earlier (e.g. "we can't make that", "we already have a part that is almost identical to that",
"our customers don't want that", "that's going to cost a fortune"...)
- Herky jerky priority changes cause people to forget what they (and others) were working on when they abruptly left off several months ago
- Expediting to "rush" projects through the system
- Low-priority projects that never ever get completed — because they are obsolete by the time they are finally cancelled
- The downstream engineer or production manager secretly "fixing" what the upstream specialist did (usually without documentation), because they know it would take forever to send it back through proper channels
Solutions for common objections
to Concurrent Development Teams
Objection: “I'm a trained specialist. It would be a waste of my unique training & talents to move me somewhere with a bunch of generalists.”
Solution: Rotate specialists onto and off of Concurrent Development Team assignments. Once a project is successfully completed, assign the specialist to work on some projects within the main departmental office for a
while — and/or send them to advanced training so that their specialist skills & knowledge remain sharp and current.
Objection: Design work flow is uneven — so dedicated team members will be underutilized.
Solution: Team members usually have far broader skills than they have ever been asked to use (often learned by secretly re-working the upstream specialists' work for years). And they can quickly develop new skills to address specific design challenges. One team member can often help the other, and the reverse. So uneven work flow can often be corrected within the team.
In reality, it is also common to identify the need (and lack of need) for specialist skills by carefully examining the project schedule — and then assigning specialists temporarily to other assignments until their specialist skills are again needed.