1.4 Routine solutions
This is the last of our three categories, and possibly the most difficult to define because the approach is not as definite. Routine solutions involve configuration or reconfiguration of existing devices or components, without innovation, because something is broken or needs to be repositioned, or there is simply a better way to do it. If you change the locks in your house or car, you are reconfiguring them; if you tune the car, calibrate the central heating, set the coordinates for your satellite navigation system, change from an overhead lamp to a wall light, or even just change station on your television, you are applying a routine solution to a problem by reconfiguring the bits. As I write, I'm reminded of the ongoing attempt by a group of stalwarts to reconfigure the standard keyboard, originally designed to prevent the letter levers clashing on a manual typewriter, into something more user-friendly for today's computer user.
The biggest examples of challenges requiring routine solutions are, literally, physically big. Things that need configuring are often remote, such as a fibre-optic signal booster in a cable at the bottom of the Atlantic, or, at the other extreme of the planet, a satellite; both of which (as it happens) are critical to intercontinental telecommunication. Box 3 Routine solution – examples looks at some examples.
Box 3 Routine solution – examples
The Hubble space telescope (Figure 5) was conceived in the 1970s. The intention was that it would capture astronomical images, unimpeded by the Earth's atmosphere, and transmit data and images 640 km back to Earth, enabling us to answer some of our most fundamental questions about the universe. It was sent into orbit in April 1990, at a cost of about US$ 2 billion.
However, just weeks into its flight the mission was very nearly lost before it had truly begun, when NASA scientists discovered that the main concave mirror of the telescope had been ground too flat by a depth of 4 micrometres, resulting in images at high magnification that were too fuzzy to be useful.
The operators who control Hubble's flight work in team rotation, driving it 24 hours a day every day of the year, sending an average of over 100 000 instructions a week. The first opportunity to carry out maintenance, install new instruments and correct the error (by giving it 'glasses' in the shape of five pairs of corrective mirrors) came in December 1993, after two years of planning. Engineers operating the telescope trained extensively for the reconfiguration of Hubble. First the telescope had to be set aside from its usual research operations to a 'ready for servicing' condition and capture attitude, then the aperture door was closed and high-gain antennas stowed. Astronauts on board a Space Shuttle made five gruelling space-walks to carry out the installation work. Once this was completed and tested, both Hubble and the Shuttle were configured for battery charging. When charged, everything on the telescope was reactivated and it was released back into orbit. To everyone's very great relief the mission was a success, and Hubble soon began transmitting the great pictures that had been anticipated.
Why do we describe this as 'routine'? Clearly the solution being sought was not expected to be innovative – the commitment to reflective optics was unchangeable. Similarly, the cost of a series of incremental improvements would be prohibitive. What was called for, and what was done, was routine reconfiguration of the bits.
A less glamorous example is found in electronic circuit design. New amplifiers, data acquisition cards and so on are launched every year.
Many are new arrangements of standard components – resistors, capacitors, integrated circuits, etc. The problem solving here has been concerned with choosing component values and characteristics to achieve enhanced performance.
You should, by now, have a better idea of how to classify solutions to problems, challenges and opportunities. The three groups above overlap. It's possible for a solution to be equally valid in more than one group at a time. It's important to consider the context of whatever you're facing – the invention of the mobile phone was an innovation in terms of electronics, subsequent innovation by development has been largely incremental, and during this development there have been considerable routine design changes. If you're deciding where the solution to a problem belongs, try to narrow it down to its basic elements.
Group the following tasks as being problems likely to find solutions that are routine in nature, that involve innovation by development or require innovation by context:
Making a lighter ladder
Specifying components for a home-computing workstation
Defining specifications for building services in a new factory, e.g. ambient temperatures in different rooms/areas, air conditioning, waste air extraction, etc.
Designing a taller crane
Replacing lead-based solders with non-lead alternatives
Bridging a wider gap
Setting network and modem parameters for an office PC system
Designing an ejector seat for a helicopter (ouch!).
Specifying components for a home-computing workstation (selecting from among existing components)
Setting network and modem parameters for an office PC system (selecting from existing options)
Defining specifications for building services in a new factory, e.g. ambient temperatures in different rooms/areas, air conditioning, waste air extraction, etc. (selecting from among existing components)
Innovation by development:
Designing a taller crane (extend a shorter crane)
Making a lighter ladder (refine the design to reduce weight)
Bridging a wider gap (extend an old design)
Replacing lead-based solders (devise new alloys)
Innovation by context:
Designing an ejector seat for a helicopter (ejector seats were conceived for fixed-wing aircraft and can't simply be transferred to the pilot's seat in a helicopter).