From: www.itworld.com
May 11, 2001 —
""If you're anything like me, you've probably succumbed at least once to a late night infomercial offering the Universal Wrench. "It fits everything. This is the last wrench you're ever going to buy." If you too have one of those wrenches in your toolbox, then you also know that it's the last wrench you actually reach for. If you have a wrench available that is specifically designed for the job at hand, then that's the wrench that you'll reach for first. Like wrenches, we get the best results if our technology tools are tailored to the job at hand.
A few years ago I was monitoring the development of a research satellite that was designed around an application-specific integrated circuit. The ASIC required chip-level capability to execute some 40 commands. A supplier convinced the satellite developer that they should instead include 65 commands on the chip. The rationale was that a more capable ASIC could be applied to many future satellites and better production would halve the unit cost. After a 500 percent overrun at the supplier and a corresponding delay of more than five years in the satellite program, the entire product approach was made obsolete by the introduction of RISC-based processors that could get the job done with about a dozen commands. Their suffering was not entirely without benefit. An entire generation of local program managers relearned the lesson that perfection is the enemy of good enough. Every product plan should embed pathways for graceful product evolution, but one should never place the current (real) product in jeopardy to benefit a future (hypothetical) product.
In the early stages of planning a technology development project -- when the requirements are being established -- there is an irresistible temptation to expand the technology solution to solve an even broader set of product challenges. Databases are an example of concepts that typically expand as they evolve. "There's just one more data field that we'd like to include ..." The Big Database in The Sky that meets everyone's data needs is the most likely to end up collapsing under its own weight and complexity.
So the CTO faces a continuing question: Do I build a quick solution and solve the immediate problem, or do I spend a little more time and money to solve this problem and a series of other problems too? Product-line managers invariably prefer their unique solution. They like the unique approach because they invented it, and because most often it will be embedded within the product development program where the product manager can retain control and assure that delays to the product schedule are minimized. Financial types and executive management generally prefer the shotgun solution. They like the economies of scale that can be achieved when technology development costs are amortized by applying standard technology solutions across many company products.
Standardization also helps to stabilize the total technical staff and enables adaptability and continuity across products and programs by minimizing the learning curve when the company needs to reassign staff or leaders.
These critical but mutually competing objectives can be difficult to accommodate, but it's the CTO's job to navigate between these communication obstacles. The CTO finds a safe path that avoids the navigational hazards by setting up a dialogue that clarifies each of the relevant perspectives. To be effective, this dialogue must take place in an open environment where people can speak freely. Then the decision factors can be understood by all of the players and reconciled into an optimum plan -- a consensus if possible. If the variables are few, then a straightforward coost/benefit assessment should determine the best approach. If there are too many variables, then it's a judgment call. That judgment, calibrated by experience, is the quality that companies are seeking in a CTO. Seasoned CTOs are willing to tackle the tough challenges. And they are very careful about committing to build the next Universal Wrench.
InfoWorld