Why State of the Art is the Wrong Goal and Squinting is Good for Your Sight

By John G. Voeller, P.E.

Background

As businesses strive to accomplish more with fewer people, less money, and in shorter time, they often tout productivity as their banner of value. And, as businesses wander through the myriad of technology options and variations, they use "state of the art" as an invisible gauge supplied by the vendor who claims to be "at the forefront." These firms often delegate the chore of managing technology to those who seem to be "most familiar" with the industry. Too often, the result is that these firms often get nowhere and accomplish little.

Recurring Themes

As part of an effort to help our clients, we introduced a process of self-examination called an Automation Audit. On the surface, this is a detailed examination of current business processes, skill-set adequacy, tool use and needs, and other areas to determine the potential use of technology and how it will change the processes, tools, and culture of the business.

What is difficult, however, is helping a business recognize its own "mythology"--inaccurate but never-questioned beliefs of how things work. In conducting almost 100 of these audits for companies ranging from small manufacturers to one of the top two computer firms in the world, we have identified some common traits:

Technology can solve problems better than humans.

This absurdity is usually peddled by managers who are not clever enough to use their staff effectively or who make technology a goal rather than a tool. The reality is that a great technology used poorly does nothing when compared to an average, stable technology used intelligently. Good usage can accomplish amazing feats.

The newest technology is better than the old. This myth leads to the following:

The next technology will solve the problems that could not be solved with the previous technology

Those who hold this belief are "technological lemmings" who leap off the cliff to follow the vendor and the latest technology. The real tragedy is that this group often fails--usually with the same vendor--and have not learned anything from the experience. Therefore, regardless of previous mistakes, bugs, problems, failures, elongated schedules, and outright lies, they jump off the cliff again.

Serious automation projects cannot be sustained within many of today's corporate structures.

This frequently is true because the short-term "quick fix" perspective so pervasive in American firms today makes it impossible to sustain a major automation effort. Even if a project can be sustained from a funding viewpoint, the development teams are juggled repeatedly, the plans are changed constantly because of an imprecise vision, and the resources remain chaotic as the firm's stock price, dividend, quarterly cash basis, and other attention grabbers wreak havoc on the process.

We can buy general technologies that are sufficient for our needs; we can "fit" it to us.

This assumes that a vendor has looked at particular business areas, gathered many views of how these areas proceed, and built a general encompassing system. In reality, most vendors hire an "expert" who has gained experience with one firm and whose knowledge is constrained to that firm's business perspective. The "we will shape it to fit our firm" viewpoint is often a failure. In our case, we built all pieces of our system and used no commercial software. Once a company builds something truly valuable and provably instrumental to the firm's success, the last thing they want is dependency on someone else for sustaining their competitive edge. It is difficult to watch major firms strive so hard to use another company's software--when the best they can do is likely to match their competitor's best using the same product.

The boss' view is unrealistic, but no one will challenge him/her

Most of the boss' viewpoint is influenced by past experiences or how things "used to be done." Self-honesty is critical in an automation effort, and this requires candor at all levels. For example, most accept the value of having joint application development teams of users and programmers to develop new systems. The assumption is that this gets the correct process and workflow information into the development. Though that participation is critical, the most important aspect of this interaction is management's acceptance of how things really work and where the real limitations are. Joint application development will find these, but all must listen.

Vendors often appeal to firm management and the boss adopts that vendor's vision as the goal.

Remember, state of the art is the best that vendors can do, not the best that can be done. Technical choices should be delegated to those who know and understand the technology and how this technology can best fulfill the firm's needs. Top-down forcing of a technology is terribly damaging.

As firms become larger, fiefs within each firm develop their own goals--often at the firms expense.

There is nothing more damaging than a territorial vice president who spends time avoiding rather than contributing to a system that might bring only limited personal benefit, but which could bring powerful opportunities to others. The "Enterprise System" connected by the "Enterprise Network" containing the "Enterprise Data" are all useless without an "Enterprise Attitude" that most firms cannot muster.

Misalignments of responsibility and control.

The old fight between the user and the Information Services (IS) department should no longer be very interesting. Why? Because users can do most of what they need--including purchasing--without asking IS. In today's businesses, any action has significant profit, resource, and legal consequences, and rarely is the IS department on the line to take the heat. If a group must shoulder the responsibilities of the business, they must "choose their appliances," according to Steve Jobs.

Service groups are allowed to put their goals above those of the group served.

A truly maddening situation seen too often is the ease with which goals are transposed. For example, a firm wants to buy a network to connect its people, share software and data, coordinate activities, and work with their applications to do a better job. The service group listens very dutifully and selects a network system that can do some of these things, though not all. However, the new system does other things. For example, the vendor's brochure talks about the 10 reasons to buy the system. It is easier to install, easier to set up a node, easier to change a node, easier to reboot when it crashes, and many other activities that affect mainly the service group. What the brochure does not talk about is that the system does not work with eight out of the firm's 10 application programs. Even if the service group knows it will not work, they go ahead and buy the system because it eases their support burden at the expense of the firm and its users.

"Squinting" is the process of avoiding these sorts of problems

Squinting involves unfocusing, broadening our view, and refocusing on the real target of import. A few actual examples illustrate:

An engineering firm spends money to automate its design process, yet, the firm fails to realize that they are predominately automating the initial design process

The initial design is never built; it is changed many times until it is ready for use. During these refinements, a five-minute change can introduce a mistake, a miscoordination with another group, or an oversight that can cost 50 times the savings of automating the design function. By squinting, however, the consequences of change become the real focus, instead of the design effort within a discipline or group at the early stages of a project.

A company spends time carefully evaluating financial software and decides to replace its custom-built system with an Open-Systems/Client-Server approach that protects them from unplanned change and obsolescence.

The only problem is that the payback on the system is five years. The hardware, software, and training are summed and reported as the total cost. Squinting shows that business changes and new technology performance impacts--even from a system that is well used and accepted--will force a complete replacement in four years. The other six computer systems they have are "off the shelf" with an average life of 26 months before obsolescence by the vendors. In no case will a five-year payback be rational, since the company will be forced to replace the system well before payback and will be effectively "upside down" on the first investment. Either a system and usages must be found that can accelerate benefit or the expense must be honestly handled at the outset.

A firm has dutifully performed a very detailed cost/benefit analysis before attempting a major development project.

Their primary target is to be more efficient and integrated. The assumption is that putting everything into a common database will solve many problems. As they look at applications, they perform further cost/benefit analyses. Some time later, the company begins to see great resistance to the system in certain sectors, which they label a turf problem or "the old-timers resisting change." After squinting, however, it is evident that the firm did not use the analysis technique of cost/benefit/penalty/synergy which isolates penalties one group may incur, but which benefits the firm overall by creating synergy. Cost/benefit must be coupled in an integrated plan in the same manner as applications are integrated.

Often data is entered into a system by people who do not use it.

The fastest way for the firm to mess up a master system is to make someone deal with data that is not to their own direct benefit. A reduction in their productivity is a hidden penalty that must be recognized by management. The responsible group's productivity reduction must be recognized as a formal contribution to the good of the firm, even if it penalizes that group's performance. This validates their accomplishment of the task as a job responsibility. Once this is recognized, the group's resistance can disappear.

The synergy element of analyzing a planned system is equally critical. Many commercial software packages sequence information entry and usage in a manner that is out of sync with a firm's timing of data availability and use. This timing also may be badly misaligned in relation to the position and group responsibility map. A CAD system with an attached database for attributes of equipment is a wonderful idea, but a drafter entering and controlling the size and flow data for the pump specification is a responsibility map misalignment. The engineer is both knowledgeable and legally required to manage this information. The drafter should not be asked to enter this data just because the screen pops up during a drawing and demands the information to proceed. The alignment of the overall sequence, time, and responsibility map of a system in the group is the synergy factor, and all must be incorporated into a cost/benefit/penalty/synergy analysis. Looking at cost/benefit alone is not sufficient today.

A firm receives all of its facility drawings from the contractor after construction.

These drawings were used to build their facility, and now must be dutifully maintained for the life of the facility. The fact that these drawings were formatted to manage the construction effort and broken into pieces for ease of crew assignment seems to escape management attention. In reality, most firms should demand as a deliverable a very different set of drawings--maintenance and troubleshooting drawings in electronic form with intrinsic interrogation functions. The value of these kinds of drawings over several decades of the facility's life is enormous.

A firm that performs engineering as part of its internal needs has been successfully using technologies that are outside the Management Information System (MIS) guidelines.

The MIS management and a vendor convince management that these "rebel technologies" need to be reined in and mandate the use of whatever tools MIS chooses, with complete disregard of past successes, currently loaded data, and formats. Proper squinting would have shown this to be a "responsibility disconnect" in which the engineers who are legally responsible for the results of their actions are forced to use tools that may be deficient. This can make the MIS group the target of any major problems or delays, yet they cannot be legally responsible. This is not bad technology, but rather is extremely poor management, with possible legal trappings.

In each of these cases, the squinting approach could have been enormously beneficial, enabling each firm to refocus on goals, skills, methods, purpose, and most of all, an honest reassessment of the "real" problem. There is nothing new about the squinting process other than identifying it as an explicit part of any planning process and making it a habit.

Rethinking the Approach

These examples indicate a basic need for companies to rethink even the roots of their view of technology and implementation. This rethinking may be more fruitful and have greater impact than all the literature, demos, conferences, and vendor discussions might produce. The best solutions are often within the company rather than outside.

The introspection inherent in squinting used to be an integral part of solid managerial skepticism, but has been lost in the need to show "progress," in the fog of rapidly advancing technology, and in the mistaken notion that automation equals productivity. The future demands more from companies than equating motion with progress, achievement with success, or worst of all, the belief that state of the art is the best that can be done. Squinting often is a clear defense.

About the author: John G. Voeller, P.E., is Senior Vice President and Chief Knowledge and Technology Officer of Black & Veatch, a large international engineering firm, and CEO of two technology related firms. ENR awarded Voeller their 1998 Award of Excellence, their highest honor for individual achievement in the construction industry. He can be reached at voellerjg@bv.com.

The CSRF newsletter is published for SPECTEXT® subscribers and others involved in design and construction. To obtain your copy of Creating a Common Language®, please contact the CSRF Support Center by telephone at 1-877- SPECTXT or 410-838-7561 or you may e-mail us at supportcenter@csrf.org

©  Copyright 2007, The Construction Sciences Research Foundation, Inc.  Updated January 12, 2007.