Articles

Ubiquity

Volume 2012, Number January (2012), Pages 1-7

A ten point checklist for getting it off the shelf: an interview with Dick Urban
Peter J. Denning
DOI: 10.1145/2076023.2076024

Far too many R&D programs in industry as well as government result in reports or prototypes that represent fundamentally good ideas but end up gathering dust on a shelf. Ellison "Dick" Urban, formerly of DARPA (Defense Advanced Research Projects Agency) and now the Director of Washington Operations at Draper Laboratory, has had considerable experience with technology transition. We talked to him about his guidelines for success.

Peter J. Denning
Editor

Ubiquity: You've been in government and industry for a long time and have considerable experience in getting newly developed technologies into use in the field. Please describe your background and how you came to be interested in this topic.

Dick Urban: My background is in research and development working as an electrical engineering government employee for the Department of Defense for 25 years and in industry for 10 years. I have always had great interest in the entire chain of events from new concept formulation to customer adoption but have sometimes been frustrated by the inability of great ideas and creative prototype artifacts to reach the desired end state. As a program manager, I have put great emphasis on getting the technology I developed to benefit the end customer. When asked how I do what I do, I came up with the 10 point checklist. It is more of a framework on how to think about the subtleties of things important to transition than a cookbook approach. I think of it as a common sense approach to increase the probability of success.

Ubiquity: I thought it is a tradition at DARPA to include a transition plan as part of a technology development program, so that the program manager knows who the customers are and how to get the technology into their hands. Has there been a recent problem with this?

DU: At DARPA, a program manager is responsible for everything from new concept formulation to technology transition. Program managers come to DARPA for four years and are expected to create an impact on the national security of our nation. They come from a variety of backgrounds including government labs, industry, and academia; some with little or no knowledge of the military customer or the government acquisition process. It is for this reason that every new program manager enters into a discussion about the "Ten Point" within weeks after joining DARPA. The objective is to start thinking about and acting upon a transition plan earlier rather than later.

Ubiquity: I made a list of your 10 guidelines for getting technology off the shelf. Let's work our way through them. Although you have formulated your guidelines for DARPA, they all carry over into industry, is that right?

DU: Yes, they do. Let's discuss them.

Ubiquity: Your first point is "own a discriminating technology."

DU: It is really important to know the technology being developed and be able to articulate how it discriminates from other similar approaches. Uniqueness is essential. This establishes the value of developing the technology because there is no alternative when it is unique.

It is also important to understand the commercial utility of the technology. Ownership of the technology, coupled with desire for profit, can be a strong motivator.

Avoid defining the uniqueness of your technology in terms of what is possible now. You must compare it to where the competition will be when your technology reaches maturity; it still needs to be unique at that time.

Ubiquity: Your second point is "walk a mile in a warrior's boots."

DU: Put on boots and jeans and go on a field exercise, ride on a ship, fly in a fighter.

Ask tons of questions. Listen a lot. Military people, as all professionals, take great pride in what they do. They are more than willing to tell you what they do, how they do it, and offer ideas on how it could be done better.

Be critically aware of the physical environment. It influences how the people think and what they are concerned about.

Get personal. Put a picture of Sgt. Gomez on your desk and caption it with "This is the person I'm trying to help."

Learn about military doctrine, strategy and tactics. Understand how your technical goals contribute to the larger picture. Figure out what's important and what's not and how you are going to make a difference.

Ubiquity: Your third point is "have a plan but don't stick to it."

DU: Translate your technical goals and objectives into operational benefits. Draw a notional path that shows how your technology will end up in some kind of (military) product. Almost all technology development programs demonstrate end results in some fashion. Tailor these demonstrations to be something that is useful to a particular (military) customer. Make "value added to the user" a key parameter for periodic evaluation of progress. Constantly evaluate your plan against your goals and objectives and be prepared to change everything. Stir up people's thinking by proposing disruptive questions. Let that induce some chaos, then stabilize. Do this over and over. It's a way to find out whether sticking with the plan still makes sense.

Ubiquity: Your fourth point is "make a commitment."

DU: Explain to the warriors (customers) what you plan to do for them. If they like the idea, make a commitment and set a time when you will come back and demonstrate something.

Make them part of your development team. Invite them to program reviews and PI meetings. Listen to "most" of what they tell you. Don't get their hopes up and then disappear.

Ubiquity: Your fifth point is "lead your contractors."

DU: Inspire your contractors (the teams who work for you) by immersing them in the military (customer) environment and leveraging their patriotism.

Make sure they know that you are not the customer and that you will be checking with the customer to see how they are doing.

Get them to the field frequently to demonstrate capability and show progress. Don't pay too much attention to the exact wording of your contract. Things change rapidly in R&D. Do what is right and change the contract as often as necessary.

It's ok to fail. Build concept and design iterations into the process. Review frequently. Learn from mistakes. Change course as often as necessary. Let contractors know that you love them—it's what they are doing that needs to be fixed.

Ubiquity: Your sixth point is "build a constituency."

DU: Wire all your technical groups together and make them work as a team. Get them to meet frequently to discuss plans, progress, and payoffs. Create dependencies (checks and balances).

Form joint service working groups consisting of military technologist to coordinate technical approach, get feedback, learn what others are doing, and obtain ideas about new technology insertion possibilities. They serve as apostles within their service (professional community).

Pick agents carefully and then empower them. You can't do it alone. The process sometimes requires heroics. Try to make heroes out of as many of these people as possible. Don't be the only hero.

Ubiquity: Your seventh point is "work the acquisition system."

DU: Get the organization charts for your customer's (military) organization. Trace a red line through all the organizational groups through which the money relevant to your project flows. Ignore everything not on the red line.

Brief as many of these groups as time permits; tell them about your goals and objectives, potential military benefits, interactions with operational units and appropriate feedback, and plans for the future.

Tell them what you want:

1. Permission to continue to operate with their people in the field.
2. Help in performing test and evaluation for operation use (flight tests, etc.).
3. Help in establishing a service or joint service requirement.
4. Action in creating sustained budget to support the new technology.

This is a very difficult process in a time of fiscal constraint. Be persistent.

Ubiquity: Your eighth point is "look for windows of opportunity."

DU: Keep abreast of new start programs in your customer's (military) community and determine how your technology can add value to what is already being planned.

Find out when ongoing systems plan to have block upgrades or make product improvements. Work your technology toward these dates so that the program managers have an alternative technology choice.

Other opportunities are for improvements to systems that exhibit performance problems because of their age (reliability) or because the technology has failed to keep up with changing requirements.

Opportunities can be identified by walking a mile in a warrior's boots, from your constituency, and interacting with the acquisition system.

Ubiquity: Your ninth point is "be conscious of dollars and sense".

DU: Focus on the price (versus the cost) to the end customer of your technology. Understand how your technology (product) affects the price of the system it will operate in or with.

Always quantify the term "affordability." What the military customer can afford is more a matter of priorities than price. The price the military customer is willing to pay or able to afford is dependent upon how much value is provided.

Focus on price for value-added. Make quantitative tradeoffs where possible. Value-added is largely subjective but military operators can help define what value makes sense in their domain.

Ubiquity: Your tenth point is "don't forget the little things."

DU: Be constantly aware of the all the people involved: secretaries, technicians, graduate students, contracting officers, and others. Personally touch all of them and commend their performance to their bosses.

Be sincere.

Be honest.

Uphold the highest morale standards.

Set an example.

Ubiquity: You formulated these points for the military environment in which you work at DARPA. But they seem equally valid for any customer, not just a military customer. Can you comment on this?

DU: I have been told by others in government, industry, and academia that they have found the ten points helpful. I believe, that with slight modifications, they can be applied to any enterprise.

Ubiquity: Many thanks.

DU: You're welcome.

Author

Peter J. Denning is the editor-in-chief of Ubiquity and a past president of ACM (1980–82). Currently he is a distinguished professor, chair of the Computer Science Department, and director of the Cebrowski Institute at the Naval Postgraduate School in Monterey, CA.

Tables

Table 1. Ten Point Checklist

©2012 ACM  $10.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.