This article highlights that unless top management is truly interested in faster product development, lower level managers can do little that will have a sustained effect on time to market. Managers must saturate the company with the awareness that faster cycle time is a high priority, as well as why it is a high priority. The more people involved in decision-making, the more slowly decisions get made. For this reason, to hasten development, the development team must first be given what they need to function autonomously and then cut loose from all those in the organization who do not have a clear stake in the project’s outcome. New approaches will sometimes result in mistakes, and without a clear mandate from management that the process changes are worth the risk of error, no one will dare risk anything substantial. In addition to this, if management expects that its exhortations of faster time to market be taken seriously, it must recognize and reinforce all reasonable steps in that direction.
As product life cycles shorten, the race is accelerating for manufacturers to bring new products to market faster. The shorter the time between identifying a market need and meeting it, the more of a jump a company has on its competitors, who are also scrambling to be first. What was once considered fast development is now commonplace. A manager's challenge is to influence rapid new product development.
Managers stretched 20 different ways by issues crying for attention would like to spend more of their time on product development. But, there is not enough time to do everything that needs to be done. If this is your problem, you need to find the critical leverage points-activities that produce disproportionate benefit for the time invested. In our experience working with many development teams, we find such leverage points certainly exist.
The place to start is by making sure that everyone knows why faster product development is important. Make the link between speed and profit clear to all on staff. If you can't, nobody will treat cycle time improvement as a serious issue. If you do, you will be able to mobilize the whole organization behind the goal.
Unless top management is truly interested in faster product development-and shows it-lower-level managers can do little that will have a sustained effect on time to market. Managers must saturate the company with the awareness that faster cycle time is a high priority, as well as why it is a high priority. It is up to top management to clarify the linkage between speed and profit. Speed may bring a longer sales life for a product, lock in early customers, and return higher average margins due to favorable sales early in the product's life. You need to know which of these factors is most important for your specific situation.
We often find people at the team level who can't explain why the company is interested in faster product development. This is a dangerous situation, since it means they can pursue different product development strategies. On the other hand, the CEO probably has strong views on this topic, but unless those views have permeated the organization, each person will be operating from a different script. Until top management establishes and communicates the firm's rationale for rapid product innovation, results will be sporadic.
Once the initial case has been made, management must continue to communicate through its actions and decisions. When the time comes for a decision, does management turn its attention elsewhere, allowing the development team to idle while awaiting resolution? Unless management really believes its own rhetoric about the business reasons for faster cycle time, its behavior will ultimately betray its true priorities, and nothing will change.
Go to where the action is. Nobody will believe you're serious about product development speed if you don't visibly spend time on this issue. One hour spent in the lab is easily worth 10 hours spent behind your desk. Top management's presence in various departments sends amazingly strong signals to the troops about what is important. Do CEOs spend most of their time with the lawyers, accountants, or marketing people? Many CEOs go for a year without so much as visiting R&D. Elaborate dog and pony shows at quarterly meetings about the importance of new product development will ring hollow if management doesn't actually give its development team some face time.
The time spent needn't be lengthy; what's important is frequency. Short, unannounced, seemingly random visits send a powerful message. By aiming to talk with only one or two people who are reaching a critical juncture in their project, managers can keep the visit short while still communicating the project's importance.
This "management by walking around" (MBW A) also benefits managers by providing unfiltered, real-time information about a project's progress that won't be mentioned until much later, if at all, in formal project reports. By showing up unannounced, management samples the pulse of the project and can satisfy itself that all is well, or can offer help if there is trouble. A vice president of product development once observed that, in his opinion, no useful information was ever conul1LUllcated in a formal meeting. He felt such meetings always provided late information with lots of "spin" on it. He preferred to spend his time attending the weekly meetings of the team, detecting problems when they were small and easy to solve.
Many managers are initially uncomfortable with the idea of showing up unannounced in the R&D lab.
They may feel more at ease reviewing reports and spreadsheets from their offices, rather than interacting personally. If they do not have a technical background, they may be afraid of exposing their ignorance. Or they may simply not see the value of it and thus find it hard to make the time.
A possible pitfall of MBWA is that the manager will use the time to second-guess developers' decisions or otherwise compromise the team. The manager must always be aware of his role as coach and counselor, not director. By leaving responsibility with team members, managers assure the fastest possible cycle time.
Another mistake managers make is to inadvertently create more work for the team. By offering suggestions that may be interpreted as assignments, managers can needlessly slow down progress. For example, suppose the project needs a supplier of plastic molding.
By the time the manager shows up, the team has already reviewed three companies and selected the best one. If the manager also knows of a good molding company, and suggests that team members give so-and-so a call, they may not feel comfortable in saying that the decision has already been made, and will retrace their steps to please the manager.
You get far greater leverage on your time by getting involved early in the project. Resist the tendency to delay participation until late in the project, when the spending rate on it is highest.
When a project is new and unformed, management's ability to influence its direction is the greatest. As the project progresses, each decision is like a fork in the road . Other forks will result from that first decision, and it becomes in creasingly difficult to backtrack once several of these decisions have been made.
Yet most managers devote the bulk of their time to a project when it does the least good: at the end. As a project moves toward production, the spending curve tilts sharply upward, and this attracts managerial attention. Faced with a tangible product and clear issues, managers can then don the hat of firefighters and swing into action to save the day. This style of "heroic" management will often get the project back on course-but at a heavy price to the schedule and to team morale.
Although it is exciting and newsworthy to carry children out of a burning building, real firefighters spend most of their time trying to prevent fires, and managers would do well to follow their lead. Many crises could be avoided if managers would take the time at the start of a project to paint developers a vision of the journey ahead, set expectations, and clarify the urgency by setting a deadline for completion. At one Silicon Valley electronics company not only did the CEO attend the kick-off meeting for the project, but he also gave his home phone number to the team leader during the meeting. It was very clear to all participants that this project was of special concern to him.
The CEO of a midwestern industrial equipment company also demonstrated this leadership role. Customers had complained that the company's equipment was hard to install and maintain. So the CEO told the new development team that any new equipment must be able to be installed and maintained by the customer's own service people, with the ordinary tools they have on hand. This kind of guidance is all too rare. CEOs often assume that instruction is superfluous because what is needed is obvious to the team. But what the CEO considers obvious may go completely unheeded by the team, unless they are pointed in that direction.
Managers who adopt the policy of "show me what you've got, and I'll either sign off on it or correct you," unwittingly demoralize their staff. How many times can managers get developers fired up for a project if the team is repeatedly halted and redirected when nearly finished? By setting a clear course at the beginning, managers can then step out of the way and let the team run with it.
Give real day-to-day decision-making power to the project team. If you do not establish their authority early, you will never get fast decision-making. Instead, you will be deluged with requests for approval of their decisions. By truly relinquishing authority you increase the time you can spend on the really important issues.
The more people involved in decision-making, the more slowly decisions get made. For this reason, to hasten development, the development team must first be given what they need to function autonomously and then cut loose from all those in the organization who do not have a clear stake in the project's outcome. This removes many of the external reasons for schedule slippage, placing responsibility for meeting the deadline squarely on the team's shoulders. The team can be responsible only to the degree that it is granted the freedom to progress without outside redirection.
Paradoxically, upper management, despite its interest in improved cycle time, is often one of the prime causes of schedule slippage. Since upper management often is not readily available, their decision points should be kept to a minimum and carefully planned into the schedule. In this way, management can schedule time to be available so its role in the unfolding project can be completed without delaying it. If the team is as excited as top executives want it to be, every hour of downtime will deplete its energy. Although management has other pressing concerns and priorities, these are invisible to the team, which sees only delay from management.
Management must be a powerful voice to keep the project focused on its original goals. Without this, teams can go on forever enhancing any design. You need to make it very clear to the team that an imperfect product today is better than a perfect product later. If you do not, the scope of the project can get out of control.
Without vigilance, newly available technologies and market pressures will encourage the product team to enhance the concept continually, resulting in "creeping elegance."
This destroys development schedules, because the team now finds itself aiming at a moving target. Creeping elegance is particularly insidious because once new information is admitted and allowed to lengthen the development schedule, the new, more distant completion date seems to allow time for even more market and technology changes.
As the completion date disappears farther into the future, other developers believe that they now have time to enhance their part of the design, and the enhancements (and development time) grow steadily. Management can prevent this simply by holding the schedule inviolate.
Of course, there will be cases when the product concept is found to be seriously off the mark and must be altered.
These cases should be rare and will require that the entire plan for the project be renegotiated. The responsibility for spotting these occasions rests with management, and developers should be clear that their job is to focus completely on the project as described, not to watch the market for reasons to alter that plan. Management then must assume the burden of watching outside the team's restricted field of vision for broader events that could upset the project.
Finally, be persistent about supporting the required changes. People look for a chance to return to the comfortable practices of the past. Make it clear that this is not an option. Your constancy of purpose will affect everyone else. Although upper management may sincerely believe in the value of faster cycle time, it may flinch at changing accustomed patterns of business, especially its own patterns.
For example, to accelerate the development process, one electronics company in New England created a cross-functional development team and co-located the members (geographically situated them within hearing distance of each other). Team members took the initiative and, since they had all the marketing, purchasing, engineering, and manufacturing expertise right on their team, wrote a product specification. They then issued the specification under a cover memo, saying that they were ready to start designing and would consider the specification final unless they heard objections within a week.
What these go-getters heard from management at that point was, "Wait. You can't do this so fast. These things usually take months to float among various departments, and the president and general manager both want to contribute something." Luckily, management quickly reversed this stance when it realized that it was getting exactly what it wanted: vast reductions in cycle time. The executives quickly called a meeting and the specification was approved that week with only minor changes.
By encouraging organizational changes such as this, even if they are not a complete success, management encourages the team to initiate further changes. New approaches will sometimes result in mistakes, and without a clear mandate from n1.anagement that the process changes are worth the risk of error, no one will dare risk anything substantial. Plus, if management expects that its exhortations of faster time to market be taken seriously, it must recognize and reinforce all reasonable steps in that direction.
Like anything else in management, getting products to market faster requires time and attention-two things that are in scarce supply for any manager. With little time to waste, we can't afford to squander any of it. Make your time count by getting involved early and visibly with your project teams. Give them real authority and support. You'll be surprised at how little time it really takes, when you pay attention to the right things.
Firefighters spend most of their time trying to prevent fires, and managers would do well to follow their lead.