Creative People Must Be Stopped (24 page)

Using the technical language of operations, we distinguish between
serial interdependence
, whereby one task requires the output of another task as its input, so the tasks must be performed in sequence; and
pooled interdependence
, whereby the tasks don't need to be performed in any particular order. One problem is that we get the tasks out of sequence or mistake the one kind of task for the other.

I was contacted a few years ago by a woman seeking advice for developing a prototype of a device she invented; it was intended for use in a beauty salon during hair washing. She said she needed the prototype to prove the value of the idea to a potential investor. When I recommended several firms that specialized in exactly this kind of model making, she asked, “Do they charge for that?” I told her that of course they charged, that's their business, to which she responded that she “couldn't possibly spend any more money on the project.” She then revealed that she had spent more than $20,000 securing a patent for the device that didn't yet exist.

On the one hand, the patent secured her interest and ownership. On the other, the value of that interest had not yet been established. Had she established the value of the device first, which could have been done without a patent (or a physical prototype, for that matter), she would have learned whether a patent was worth pursuing or even whether securing it was the critical task that needed to be performed first. It's as if she had bought a really expensive lock, which left no money for a bike, without first checking if she might store the bike in her locked garage. She also hadn't considered whether the bus might have been the more appropriate vehicle for getting where she wanted to go.

We are vulnerable to this kind of constraint if we become annoyed at the idea of project planning—that is, of diagramming and then disaggregating a hypothetical project in gory detail. We will be annoyed because doing a good project plan is hard, because a good plan has the danger of exposing important weaknesses in the complexity or resource requirements of our pet idea, and because planning requires spending time on the details of a project that we are not even sure is worth doing.

Long Feedback Loops

Another critical aspect of time is that of feedback. The time between when you try a new action and when you get a sense of the success of that action can be critical and difficult to control. In his book
Why Things Bite Back
, Edward Tenner (1997) chronicles a number of landscape-altering examples of people introducing significant innovations on the basis of a thoroughly unconscious and incompetent understanding of how the innovation itself worked or how they would be able to tell whether or not the idea was working and therefore a good idea (or not). Kudzu, for example, is a vine introduced to the United States from Japan in 1876 and promoted not only for use as an ornamental plant but also to feed grazing animals and control erosion. It was widely planted from the 1930s into the 1950s by the Civilian Conservation Corps. Subsequently it was discovered that the conditions in the southeastern United States were
too
ideal for the plant, and it grew out of control, choking out native vegetation and invading cropland, and continues to do so to this day. Estimates of the value of lost cropland and the cost to control the plant exceed $500 million annually; the rate of spread in the southern United States has been estimated at over 150,000 acres per year.

In the case of the drug thalidomide, there was a yearlong lag between when the mothers took the pills and the first affected babies were born. Then there was the time it required to track down the source of the problem; it took four-and-a-half years from the birth of the first affected baby to the identification of thalidomide as the cause.

Time Required for Learning

Besides Maslow's model, there are others describing the progression of learning, one of which bears mentioning here. The
learning curve
(
Figure 7.2
) represents the amount of learning that we have achieved on the vertical axis, against the progression of time along the horizontal axis. The characteristic
S
shape is believed to characterize all learning, in that it starts slowly, accelerates rapidly, and finishes in a plateau where it again grows slowly if at all. This is the path we take from our lowest levels of competence to our highest levels of mastery. Given that all new efforts are subject to a learning curve, it is surprising how easily we may fail to consider the rate at which learning will need to occur in organizations to address even relatively simple new problems or innovation initiatives.

Figure 7.2

The constraint begins to show when we underestimate the time it will take to develop or even acquire sufficient competence in new endeavors. Consider how easy it is to underestimate the time it will take to do the things you already know how to do. Overly optimistic views are also vulnerable to the usually faulty assumption that the people being asked to do the learning actually want to learn, or that the people we have engaged to teach us, whether through contract or acquisition, actually want to transfer to us the skills that have made them valuable. If we do our resource and time planning based on systematic underestimates, we can find ourselves in a position where there really is insufficient clock time to do what has to be done at a level that makes it worth doing.

Consulting firms and educational institutions sell learning as their product and are thus able to realize a return on learning, or exploration, which might otherwise be considered wasted. It also helps that the client (or student) is the one paying for the learning. However, organizations that value the application of knowledge exclusively over the generation of knowledge tend to give learning short shrift. Being focused on implementation means you want to get to that point as quickly as possible without investing in any learning that does not have immediate use. You may be in such a mode when, for example, a water pipe breaks under your house. Although it may be of intellectual interest to get a conceptual overview of municipal water distribution systems and to learn the finer points of the materials, diameters, and thread sizes of various pipes, you really just want the thing fixed, and fast.

The bias toward application, or exploitation, shows up when a project plan includes little or no time for learning. This omission may be caused by pure forgetfulness or by a value system in the organization that would look down on a plan with lots of time built in for wasteful activities like learning. In either case, the result, insufficient clock time, becomes a constraint.

Overcoming Time Constraints

By questioning our assumptions about time, we gain the ability to make better decisions about how we spend it in our attempts to overcome technological barriers. We can also gain a much better sense of whether our plans will, in fact, enable us to meet the market need in a meaningful way. What follows are several strategies for overcoming the constraints caused by our assumptions about time.

Leave Time to Learn

Develop a project plan to enable you to surface your assumptions about the tasks involved. Be aware of the tendency to underestimate the overall amount of resources that will be required as well as the amount of time that will be needed for learning.

Project planning is not necessarily a fun task, and you may find, even for simple problems, that you get a feeling along the lines of “It'll take longer to plan this thing out than to actually do it.” Ignore the feeling: the analysis will help you develop the optimum way to perform the task. If you don't have time to do this, you probably don't have time to perform the project, either. Consider this to be the necessary work of innovation. Also, if it is a complex project, use a project management software tool.

First consider the time you have allotted to learning, if any. You might check with others who have performed a project with similar learning requirements to see what their experience was. Recently I examined a plan prepared by an outside vendor for the installation of a new accounting system for a business I worked with. There was a great deal of time demarcated as “training” in the plan, but no time denoted as “learning.” When I asked if the time estimate was realistic, I was told that it was, “so long as nothing unusual happened.” When I asked how often nothing went wrong, the installers eventually confessed that they always ran into some kind of problem, but then reasoned that because the problems were different from customer to customer, they couldn't plan for them in advance. Either it had not occurred to them that they
could
plan for “unforeseen problems” or learning, or they were reluctant to admit to a client that they themselves would also need to learn; after all, as experts, they were supposed to know exactly what they were doing.

Of course experts need to learn. That's how they become experts. Make sure you don't crowd out this legitimate activity in order to make the project appear shorter or cheaper, or yourself appear smarter. If your resources are insufficient (including cognitive resources), it's better to know that up front than three-fourths of the way through.

First Things First

As you break the project down into its likely tasks, figure out how the tasks depend on each other. As noted earlier, some may have to be performed before others; some may not depend on others in any obvious ways. Software tools can automate this process, and some can even suggest an optimum sequencing based on the time estimates, sequencing, and dependencies you have established. You should also consider the possibility of disaggregating and then rearranging the order of the tasks to see whether any tasks can be done in parallel, thus reducing time to finish. A software program can do this for you automatically, but you can do it manually as well.

Once you understand the basic tasks and their dependencies, and believe that you have enough time overall to do the project, you must now try to “pull” the most critical parts of the project toward the beginning of the project. For example, the woman with the hairdresser invention could have moved the task of finding an investor earlier, before the task of applying for a patent. If she couldn't get interest from the investor on the strength of the idea itself, a patent was not likely to make it suddenly interesting. A lack of interest is also a telltale sign that the idea is probably not worth a $20,000 patent. Exploring her project plan further might have suggested that even before pitching the investor, she should canvass some other beauty salons to determine whether there was a general interest in the product or whether it had meaning only for her. If there was interest, she could have documented that interest to convince the investor. If not, she could have used a small part of the $20,000 to have the device built for her to use in her own shop.

Don't avoid building a plan for fear of finding out how hard the project really is going to be; that's the only way you can construct a schedule that won't create a clock-time constraint. And don't be afraid to test the showstopper question; if your idea is not as valuable as you thought it was going to be, the sooner you find out, the better.

Watch the Clock

Estimating the time a project will take can provide an important opportunity to examine the difficulty of the approach being planned. If the timing seems unduly long or puts the innovation beyond an available window of opportunity, probe the assumptions that underlie the estimate. For example, you might ask if there is a simpler and faster path to an acceptable result, or even some way to simplify the innovation itself—for example, by giving up certain features. Aspiring innovators (especially young engineers) are often drawn to more complex solutions than are needed to yield an optimal result, while also underestimating the time that will be required to achieve it. In contrast, more experienced innovators and good managers are able to discern those points of diminishing return beyond which a solution may well be more technically or philosophically correct but where the cost of reaching it is out of proportion to the value. It may be that a 50 percent solution reached on time may be preferable to a 100 percent solution that is arrived at too late. By the same token, there are occasions when an additional cost in time to get to a genuine breakthrough may be worth incurring despite earlier assumptions about the window of opportunity.

Mind the Learning Gap

When we wait for others to innovate first, as Kodak did, we run the risk of finding ourselves in a position from which we cannot catch up. Of course we know that learning takes time, but when it occurs outside our direct gaze—for example, inside our rival organizations—we may not see the length or the difficulty of the learning that was required for competence with the new innovation.

But there are time-based tools we can use to monitor the gaps that exist between the functionality provided by current technology and the functionality that will be needed for future innovations. The
technology roadmap
is a tool to assess the timing and rates of development of technologies that have a potential to impact current products and future innovations. Roadmaps represent the major functions, technologies, or components of the product or service as rows in the vertical axis, while time progresses horizontally in columns from the present to future, from left to right. Each cell indicates the projected state of that particular technology at that point in time.
Figure 7.3
illustrates a roadmap for the goal of having a thriving human colony on planet Mars. (This roadmap is adapted from one published by NASA (Kennedy et al., 2010) and has been altered for explanatory purposes.) The columns show time in five-year intervals from now until 2035; each of the six rows indicates a functional requirement that is integral to the success of the project. This roadmap lets NASA forecast and track the level of development of each of the important technology layers needed to fulfill the mission. If the project's managers find that a particular technology is falling behind schedule, they can make additional investments in that area to speed up development.