Expert Advice on How to Complete Design Projects Faster

 

An interview with Engineering Department Management & Administration Report (discontinued in September 2000), Oct 1998, pp. 1, 10-12

Conducted by Joseph L. Mazel, Editor

Readers have told us, loud and clear, that their most challenging problem is in not having the available resources to complete the new projects that continually come into the engineering department. EDMAR has heard your distress, and consulted with a leading authority on the subject of overload, Preston G. Smith, president, New Product Dynamics (Portland, Ore., 503-248-0900; preston@NewProductDynamics.com).

In this exclusive interview, Smith (who co-authored with Donald G. Reinertsen, the highly acclaimed Developing Products in Half the Time, Van Nostrand Reinhold) shares his observations and provides EDMAR readers with many valuable suggestions on how to successfully overcome their "overload" problem.

EDMAR: You've reviewed the responses to EDMAR surveys and noted the large number of engineering managers citing staff overload as a major complaint. Based on your expert observation, how real a problem is the overload situation?

Smith: I believe it is real. Although it may be a reaction to downsizing sometimes, it shows up in virtually every company I have worked with-even those that have grown in staffing.

The real cause, I believe, is that product development has gotten to be a far more demanding game in the past few years. Markets have become more global, operations have decentralized, customers want more complex products. And they want them faster as competitors have gotten better, and their expectations of product quality are higher.

Even though staff may not have been cut, companies are relentless in trying to cut costs. So they expect more new products per unit of expense. Unfortunately, the common consequence of this is to overload the new product pipeline.

EDMAR: What are the signs an engineering manager should look to bolster his/her case that there is, in fact, an overload in the department?

Smith: I have a list of nine symptoms of overload. They include:

1. Projects get staffed slowly or weakly after being approved;

2. Schedules slip on all projects;

3. People jump frequently from project to project;

4. Priorities shift constantly;

5. Scheduling meetings is almost impossible;

6. People often say, "I haven't had a chance to get to it yet";

7. Engineers split their time among multiple projects;

8. Processing queues in drafting, the model shop, testing lab, and other locations; and

9. Many dormant projects.

EDMAR: What is the most responsible way for our readers to approach this situation and to get it "manageable" again?

Smith: To provide a compelling case for action, it is necessary to discover facts from the organization's own history that show how big the overload problem is, where and how often it occurs, and what benefit is likely to follow if it is addressed.

Because this issue occurs frequently, we have addressed it often and have found several ways to collect such a base of facts. You can show how large the list of dormant projects is, how often projects or their critical tasks sit in queue awaiting resources, how big the backlog is for an individual engineer, and how much faster a project could be completed if it were staffed fully.

Sometimes it is best for someone outside engineering to lead such analyses, so it won't appear that the engineering manager is just trying to get an unreasonable portion of the company's resources.

More important, such overloads are not the exclusive problem of engineering. In fact, the critical bottlenecks are often in other areas, such as marketing or purchasing. Thus, although the engineering manager is an ideal one to initiate such inquiries, it is unwise to restrict the analysis or the assumed solution to engineering.

EDMAR: What tools and techniques are best applied in this restoration process?

Smith: No specialized tools are needed. Ordinary spreadsheet and presentation software, or even a pad of paper, is all that is required.

The trick is to customize the approach and the facts to the specific organization so that the identity of the issue is blatantly clear. However, the tools needed to address the issue once management, including engineering management in some cases, is convinced that there is an issue debilitating enough that it is worth correcting, are again very simple.

The principal one is extremely simple to describe, although it is not so easy to apply. The tool is simply the ability and willingness to say "no" to new projects coming into the system. This "no" approach does not mean "no, never," but it does mean the discipline to say no until sufficient resources, usually human resources, are available to adequately staff the new project. If one wishes to start a new project before resources are available, then the decision is: Which ongoing project will be terminated so that resources are available to start the new one?

Again, please note, this tool most often must be applied outside engineering, because the main entry point of new projects into the organization is not in engineering, but in marketing, product planning, or top management.

EDMAR: What metrics should be used to validate and substantiate what is happening in the new development process?

Smith: The best metrics are those targeted specifically to your organization's major current weaknesses. For instance, if you find the bottleneck is in the drafting department, then measure the queues in these areas until another area becomes the governing constriction.

It is best to find the leading indicators of problems. For instance, you get advance notification if you measure queues in drafting rather than cycle time there, because long cycle times materialize after the queue appears.

I urge clients to participate in establishing metrics, as I encourage their involvement in any type of solution finding. They tend to create the measurement scheme that fits their situation best.

EDMAR: How should engineering managers approach the overload problem and present it to their management without fear of jeopardizing their career, or being considered an obstructionist?

Smith: Unfortunately, this depends greatly on how open the culture of the company is regarding improvement. Some senior managers are clearly concerned about these issues. In other cases this would indeed be a career-limiting move.

That said, I've learned that each company has a "window of opportunity" for considering these issues. If you approach them before there is enough pain surrounding the issue, you are not likely to be taken seriously.

But if you wait until the situation is desperate, management is overwhelmed by crises. In between is the opportune time.

I would approach this as a company-wide issue to be addressed by the company management's team. Show that, as engineering manager, you are willing to own your part of the problem and associated solution, but that you believe there are important parts of it outside of engineering, too. Give examples of queues and delays in various parts of the organization, including engineering.

EDMAR: What are your thoughts on the impact of technology (3D CAD, PDM, rapid prototyping, ERP) and whether it can contribute to resolving the overload problem?

Smith: These technological enablers can be part of the solution, but they are not central to the solution. 3D CAD, for example, can improve productivity for repeat designs, but it sometimes consumes more resources than previous methods for new designs. Moreover, there will be a steep initial learning curve and a large purchase investment, so, in the beginning you will get farther behind before you start to gain.

As long as we are considering making these kinds of investments, why not consider investing in people? After all, this overload phenomenon is just a mismatch between the number of projects underway and the number of people on hand to work on them.

An attempt to fix the problem by adding people, or by getting technology, which is just a substitute for labor, will only be a temporary fix. Before long, the list of projects underway will grow to exceed this enhanced capacity. In the long run, these overload issues cannot be resolved by adding any kind of capacity.

The answer must come on the side of curbing the appetite. Sooner or later we must learn to say "no." Otherwise, our appetite will continue to grow to always outstrip our current capacity.

Product development interviews  |  Product development publications