Mind the Gap
Dr. Joel Orr

Many years ago, on my first visit to the London “tube,” the wording of the warning signs regarding the distance between the train and the platform struck me. It has since come to mind whenever I think about physical or metaphoric distances that merit my attention.

The gap of concern for this column is one that is familiar to every engineering professional—yet “minded” by very few. It is the gap between what computer software technology can do for engineering and what it actually does.

I attribute this gap to three major factors:

• Credibility
• Process issues
• Organizational structure

The first factor, credibility, is easy to understand, if you think about the dynamics of the software business. A vendor comes out with a software product. They offer it for sale. If it is innovative, if the customer has not seen it or something like it in action, they are cautious. Will it live up to the salesperson’s claims? How will we use it? Can we afford to try it on this mission-critical task?

The salesperson has responses to all the questions, of course. But can the customer believe them?

Are there testimonials? Can the customer speak with someone who is using the product in an application similar to the one contemplated by the customer? Can the testimonial-giver be trusted?

The cost of trying out a software product is far greater, typically, than the cost of the product. Schedules are at stake. If it fails to work as claimed, consequences may be nothing short of disastrous.

Customers can simply not afford to believe sales pitches or even testimonials. It is a rare customer who can see the wisdom of trying something new when there is no pressure to do so, and there is little at stake.

Process issues are the second factor. Most manufacturing organizations have a way of doing things—and seldom is it accurately documented. Wise managers who live by deadlines do not fiddle with the process, because they know it is not well-enough understood to be easily “fine-tuned.”

New software is very rarely a “plug-n-play” replacement for a manual process. Proper implementation typically requires extensive rethinking of operational issues—personnel shifts or even reductions may be called for. Getting full benefit from the software will probably necessitate large changes in information flow and work flow.

Such changes are not attractive to the schedule-driven manager, regardless of the benefits promised by their institution. Again, it’s a matter of risk. Failure is not affordable.

But I believe the third factor, organizational structure, is the one that is most responsible for the gap between what software might do for engineering and what it actually does.

Here’s why.

Manufacturing organizations have a set of motivations that drive them—things like profit; shareholder value; employee values; quality; and so on. You can read about them in the company’s business plan, or in its annual report.

But the entities charged with taking the actions and decisions driven by those motivations are individual people. And it is an unusual organization whose management had done what is required to insure that the forces that drive the individuals line up with the organizational motivations.

As a simple but real example, consider the individual’s need for job security. The software vendor demonstrates a product that will substantially increase corporate profits, if properly implemented. The evaluating engineer sees the potential for the organization, and it is good, and the risks appear low.

But that same engineer realizes that the software, once implemented, will take over 40% of their job functions. The most interesting 40%.

What’s this person to do? Move ahead with the software to obtain the gains for the organization—and risk changing their own job for the worse, or losing it entirely? What is the benefit to them for helping the organization in this way?

Or will they find reasons not to try the software? That way, their job is safe. Nobody is likely to find out about the opportunity lost to the organization.

This is not a deeply hidden problem. It is understood by most organizations. Yet few are taking steps to deal with it, to attempt to align individual motivations with organizational concerns. This represents a great opportunity for the wise engineering manager.

So what will the wise manager do? It’s not a trivial matter. There are probably many models on which to base a response to this challenge; here’s a sketch of a possibility:

• Recognize that individual motivations vary widely. Older team members may be seeking security, while younger ones may be more interested in earning more, and in learning cutting-edge technologies to make themselves more marketable—both within and outside of their organization.
• Assemble diverse teams, so that the individual needs of team members can be aligned to suit those of the organization. Offer to reward individuals and teams for taking greater personal risks.
• Set up personnel evaluation schemes that reward risk-taking, even failure.
• Institutionalize the process of dynamically designing team composition and compensation to match current project needs.

Mind the gap.

Dr. Joel Orr can be reached at joel.orr@cyonresearch.com.