Does product development take too much time in your company? Even if your firm has such important ingredients for success as attractive product ideas, technically competent employees, and use of product development teams, product development may seem to take too long and cost too much to make your firm competitive in the marketplace.
Perhaps the problem is you are trying to put new wine into old wineskins. Implementing a new program within an old organizational culture will hinder the program's effectiveness.
Continuing to use compartmentalized, functionally divided organizations that resemble a salad bowl of subcultures will create problems that could end in chaos. Each subculture—engineering, manufacturing, marketing, field service—has different "thought worlds" and new product development (NPD) processes that tend to follow linear paths. Their internal decisions tend to complicate the process for others and extend project time and cost. Unless your firm changes the culture as it changes its methods, it may be only giving lip service to improving product development.
A problem of over-optimism. Most people correctly believe cross-functional product development teams that use an agreed-upon process will reduce development time and cost. The problem is managers often believe and act as though this approach is so rational, obvious, and compatible with their existing organizational culture that the employees will take to it like a duck takes to water with little or no effort required to modify it. I've heard managers say, "Just give them the description of the NPD process, and they will implement it. Don't waste time focusing on the organization's culture."
The key to effective and efficient NPD is to establish cross-functional teams BUT with the proper leadership. Product-team leaders should be the key shapers of product innovation and the key managers of interpersonal dynamics among team members. They must build trust, foster openness and encourage risk-taking so that highly creative products are developed faster and less expensively. They must protect the team's autonomy, break down traditional departmental loyalties, create a unified focus on product development, increase speed of product development, and ensure the proper tradeoffs are made.
A shortage of effective leaders. The problem in many firms is a shortage of people who are technically competent and product development leaders. Too many project team leaders are technical gurus who devote almost all of their time to micromanaging the design with little or no attention to providing project leadership.
On the other hand, effective leaders focus on increasing every participant's personal and emotional commitment to the team and it's activities. In future issues, we will discuss cross-functional teams and their leadership.
Q: What is blamestorming?
A: According to Bill Werst (see his article, "Fixing the
Problem, Not Affixing the Blame," in the June 2000 issue of Innovative Leader ), blamestorming is a time consuming, nonproductive, interractive group discussion which focuses on determining why a mistake was made and who made it.
Focusing on these factors is a waste of valuable time. Moreover, the larger the mistake, the less likely anyone will take the responsibility for having made it.
Most people and organizations habitually pursue blamestorming rather than problem solving. Mom and dad, the primary trainers of future managers, ingrained us in blamestorming. Typically, after an in-home disaster they asked, "Who did this?"
So in time we learned to deny, hide, and improve our communication skills in blaming someone else, or something, for the disaster. As we grew up and entered organizations, we brought our blamestorming skills along with us.
People naturally and comfortably form into blamestorming committees. They may not know how to fix the problem, but they are adept at blamestorming.
Common sense managers manage problems by immediately seeking a solution. They save valuable time and resources by skipping why it happened, and who caused it. They direct their resources toward determining what needs to be done to fix it.
Generally, customers don't care whose fault it was that their machine
malfunctioned. They just want to know their product will arrive on time, and
that it meets their quality and price requirements.