September 2013 Download this article as a PDFAbstract

Effective time management is a critical success factor for most projects; however, it is particularly challenging for projects involving substantial innovation. For most projects, time (i.e., the schedule) becomes a management "red flag" that signals when something goes wrong or gets out of control. The challenge for projects involving significant innovation is that one or more critical activities may be of an unknown duration or involve factors outside the normal design process and require "red flagging" from the outset. Managers of innovation projects have to distinguish between those activities or work packets that are a part of “business as usual” and those that involve innovation. They must identify and quantify the schedule risks and develop strategies to mitigate them. For example, one strategy to manage time-related risk is to decouple the innovation value as perceived by the customer (innovation output) from the technology innovation that is needed to deliver the product value in a cost-effective manner (innovation input). This strategy should take into account the likely consequences of longer-than-anticipated innovation time. Two common risks associated with poor time management for innovation are running out of financial runway to reach sustainable revenue and missing a critical market window. In this article, the author reflects on almost 30 years of experience in the Canadian innovation system across several industry sectors and provides some practical recommendations on time management for innovation managers.


To say that time is not on the side of innovation is an understatement. Although time management is a challenge in any commercially competitive situation, it seems to be particularly pernicious in an innovation environment. Most projects run into scheduling issues and unexpected events. Experienced project managers develop strategies to deal with these problems. Projects involving significant innovation have proven to be particularly risky; startups have a high failure rate and new initiatives in small- and medium-size enterprises often stumble. Is this just the nature of innovation or are there ways to shorten the odds and improve innovation performance? The intent of this article is to help the project manager to identify activities or work packets with a significant innovation time risk; to devise a time management plan that will increase the likelihood of success; and to mitigate the consequences of schedule slippage.

Early in my career, I was project manager for a sub-system for CANDU nuclear reactors. The patented technology allowed this sub-system to be built for less than half the cost of a conventional solution. The two-year project had good margin, the client saved a lot of money, and, despite a number of unanticipated delays such as a key supplier declaring bankruptcy and components requiring requalification to nuclear code, good project management practice ensured that the project arrived on time and on budget. It was a textbook case of high-tech, win-win innovation.

Jump forward a couple of years to one of Canada’s flagship telecommunications companies in the ramp up to the "tech boom". I was involved in technology development on projects in several different lines of business. Initially I was perplexed at the frequency of significant schedule slippage. The details differed in each case but the outcome was quite consistent. Some blamed it on "scope creep" from customers (a valid project management issue). Some claimed that “senior management” always doubled the estimate so, if they were honest, the project would never be approved (a management culture issue). Finally, one insightful project manager admitted that, although the project seemed to be a standard software release, the critical components had never been developed before, implementation just turned out to be harder than the architects had anticipated, and activities outside the normal design process had to be added to the schedule. I will return to these issues shortly, but for the moment it is sufficient to say that this insight helped me to deliver innovative technology capability more effectively to product development teams and later to help a number of small companies in their innovation processes.

In this article, I clarify what I mean by “innovation” and its relationship to product development and to new technology development before moving on to a discussion of time management for innovation. Some examples are presented that illustrate how innovation may affect common trade-offs in product development and the consequences for time management. I then look at some of the broader corporate implications of innovation, including the development process, supply management, and manufacturing considerations and show how they may affect the time required to commercialize an innovation, particularly if they are not taken into account up front. I make some observations regarding culture and behaviour and touch on the issue of innovation collaborations with outside organizations. Finally, I conclude with four simple recommendations that should apply to most innovation projects.

Innovation Output vs. Innovation Input

Innovation is a word that is frequently used by people for whom it is a rather abstract concept. The definition for “TPP Innovations”, developed by the Organization of Economic Cooperation and Development (OECD, 2005), is one of the more practical:

"Technological product and process (TPP) innovations comprise implemented technologically new products and processes and significant technological improvements in products and processes. A TPP innovation has been implemented if it has been introduced on the market (product innovation) or used within a production process (process innovation). TPP innovations involve a series of scientific, technological, organizational, financial, and commercial activities."

This definition works in many situations and draws a clear distinction between innovation, invention, and research (concepts that are frequently confused); however, it does not help the project manager improve their innovation performance in terms of time management. In this article, the term “innovation” will be used in two different ways: i) for the “wow factor” experienced by the customer of a product that they see as innovative; and ii) for the (few) activities or work packets within an overall product development schedule that deal directly with the incorporation of new technology. For example, when my children said the iPhone 5 was innovative, they were referring to a perceived user “wow factor”, not to the innovative technology that had gone into the smartphone.

In this article, I will refer to the customer “wow factor” experience as “innovation output”. Innovation output may be thought of as a new design concept that meets a latent market need. Productizing that design concept may be enabled or facilitated by new technology (an innovation input) or it may be achieved using a conventional design “toolbox” employed in new and different ways. In the former case, significant schedule risk may be incurred due to new, unfamiliar, and immature technology. In the latter case, the implementation and execution should proceed according to a standard design process following good project management practice.

The biggest time risk related to innovation output is missing the market window; either someone else gets there first and steals your “wow” or the product arrives before a substantial portion of the market is ready for it. There are many great ideas that arrive before their time. The Apple Newton jumps to mind or, for fans of Canadian innovation trivia, the Archie search engine – the first Internet search engine – is another example. Hitting the innovation market window is an art beyond the scope of this article; however, the risk of missing the window is clearly exacerbated if the development schedule contains substantial uncertainty due to innovation.

In this article, I refer to the incorporation of a new piece of technology into a product as “innovation input”. This technology may come from an in-house R&D effort or from external sources such as a supplier or a university/college innovation program. An innovation input may be linked to an innovation output or it may be completely transparent to the end customer. In the latter case, it may give a designer the opportunity to provide the same functionality at a much better cost than the competition or to improve profit margin over the product lifetime. I was involved with the packaging of optical communications modules in the 1990s; innovation inputs allowed year-over-year footprint shrinkage and functional integration of devices that resulted in substantial cost savings and reliability improvements. From the customer perspective, it was fundamentally the same box with the same optical communications interface, although new features were added to reduce the cost of ownership and ease of management.

There Is a First Time for Everything

Time risk related to innovation input comes because managers do not know how long something is going to take the first time it is done. They can infer how long it might take from previous experience, but the more innovative the technology, the more likely something unexpected will arise. For example, when signal speeds on backplanes started to approach one gigabit per second, there were a number of useful design techniques that could be borrowed from microwave engineering. Capacitive coupling of signals across connectors was one of these techniques. The technique worked well in terms of signal integrity, particularly when hot-swapping printed circuit packs, but functionality was impossible to test using standard test methods. As a result, debugging became very difficult and this one work packet held up the entire development effort.

Time management risks for innovation inputs and innovation outputs are different and require different mitigation strategies. The first step for the project manager is to clearly identify and understand them.

Decoupling Innovation Output from Innovation Input

An important question for the innovation project manager is whether the innovation inputs and innovation outputs are tightly coupled. If they are, then the time management risks are also intertwined and harder to manage. Sometimes, there are alternative ways of delivering the innovation output that are disassociated from the technology risk of innovation input. These ways may be less attractive as a long-term solution for reasons such as cost but can provide a short-term de-risking strategy or a fallback plan.

For example, in the case of a wireless system that I was contributing to, the internal development using innovative technology from a university program got "bogged down". In order to meet delivery dates, an early version was built largely from off-the-shelf components and with technology licensed from another supplier. The margins were not great and the form factor was not ideal but the product achieved the desired foothold in the market. The new technology was introduced as a product enhancement when the design team was comfortable with its level of maturity. In a contrary example, a major electronics company introduced several products that exploited the performance characteristics of carbon nanotubes to establish a market leadership position. I followed up to see whether the technology could have other applications only to discover that, with more work, they had found that they could achieve the same performance characteristics (innovation output) at a lower overall cost through different processing of more conventional materials. The market window was seized using the more exotic solution but then the innovation input was engineered out for long-term profitability.

Technology Development vs. Product Development

Technology is another of those words that means many different things to different people. As a technology development manager in a large R&D organization, I saw my role as providing the product development community in the company with proven, proprietary “tools and techniques” that the competition did not have. When time permitted, these new technologies would be fully vetted and trialled in prototypes before they were transferred into the product development process. Ideally, device technologies would be available from more than one source and would be fully compatible with standard manufacturing capabilities. NASA pioneered the useful concept of technology readiness levels (TRLs). In this methodology, a technology has to meet a certain maturity level (TRL9) before it can be used in a product. In many industries, an attractive new technology and a "hot market" can drive the decision to use the technology before it is fully mature, that is to say at a lower TRL. Jumping the gun on technology maturity transfers time management risk from the technology development process to the product development process. This business decision is valid in a highly competitive environment so long as management is fully aware of the context and consequences and modifies their development schedule accordingly.

In another example, a variant on this scenario occurred when the product development team believed it could meet the performance targets of the product using proven design methods only to find out late in the process that they were going to fall short. The response was to seek a solution based on an untried technology, despite the low odds of this approach being successful in the available time. The resulting time that was spent on this search for a technological solution was much longer than if the technology development team had been brought in early in the process. On the plus side, the development team had someone to share the blame for the slippage, and for the next time, they had learned to start the dialogue earlier.

The discipline of separating invention/creation/discovery and maturation risks associated with technology development from the execution/delivery risks of product development is becoming harder to maintain in large corporations and is, for the most part, absent within smaller organizations. It is, however, a useful concept to retain when it comes to understanding time management risk in innovation due to technology maturity issues.

Product Development Process vs. the Development Environment

Product developers hopefully work within a clearly defined corporate development process defined by a suite of tools and a comprehensive set of rules. At the beginning of this article, I referred to design problems that were simply harder than anticipated. These types of innovation challenges will stretch the development process but generally they will not break it. Unfortunately, some innovations violate rules that the product developer was not even aware existed or may have completely unanticipated consequences that severely disrupt the schedule. The former is more common in a larger corporation with a long product development history, whereas the latter tends to be the case in smaller, younger companies.

As an example, in one project that I was managing, thermal modeling showed that better heat transfer was required between the chip and the printed circuit board to meet temperature limits for reliability. A new epoxy underfill was developed with a resin and a hardener in time to go to production. Manufacturing rejected it because the two components did not mix in exactly equal quantities. Based on past experience, they were convinced that eventually there would be a mistake on the floor, the two components would be reversed and a recall would happen. We definitely did not anticipate that response. The lesson is: talk to manufacturing early in the process to see if there are any unwritten rules that will stop a great idea dead in its tracks.

Three questions I have learned to ask early in an innovation development activity are:

  1. Is the innovation supported by the tools suite being used by my developers?
  2. Do I have the means to test the innovation to confirm it is working or debug it if it is not?
  3. Does the innovation meet the needs of supply management?

Hardware, software, and system designers are increasingly dependent on sophisticated tool suites that prevent many errors, speed up development, increase manufacturing and production yields, etc. However, new and innovative technologies may require updates to the tools in order to integrate them with the rest of the design activity. One early example of this challenge that I ran into in the late 1980s involved trying to include devices with a metric footprint in a North American printed circuit layout tool that used imperial units. You could "kludge" it in using inelegant work-arounds, but that approach had all sorts of downstream implications. At the time, it required extensive negotiation with the tool vendor to add an adjustable grid-size feature and database modification, which added weeks to the development schedule. As a general rule, an innovation that cannot be incorporated into the tool suite is not going to make it into the product.

Testing is an essential step in the product development process. Test equipment or test programs can have a great deal of functional flexibility; however, they often have significant constraints in terms of interfacing with the product. Several times, I have seen excellent innovations hit a major roadblock because the test vectors could not observe internal error states or because the failure modes of the new technology were not well enough understood to test for them efficiently, effectively, or to the satisfaction of the client.

Then there is the relationship between the innovator and supply management. As a technology developer, I was frequently frustrated by the number of arcane rules that needed to be followed to bring a new technology into manufacturing, ensure ongoing security of supply, meet all the regulatory requirements, and avoid licensing problems relating to issues such as software re-use. When digital speeds first started to get up into the hundreds of megahertz, the signal quality deteriorated quite rapidly unless expensive radio frequency substrates were used. Layout rules were soon developed that could circumvent these problems, but the material characteristics that determined propagation speeds on low-cost commodity substrates were only specified by the manufacturer for signal speeds up to 20 megahertz. Not only would electrical properties above these frequencies vary significantly from vendor to vendor but also from batch to batch and with changing humidity without any indication in the specification sheet.

Working with supply management, we found a single vendor whose material could be purchased using a different specification code. The performance was not particularly better than any of the other materials, but it was always the same, so we could tune our solutions for that specific material and save the company significant cost across a wide range of designs. This strategy worked until the company went on one of its periodic housecleaning exercises to reduce the number of parts codes in the stock room and reduce the number of vendors for similar items. I eventually concluded that your "best buddy" and first go-to person for a new technology innovation should be in supply management. Once they get over the surprise of being brought in early in the process and start to collaborate, your success rate at introducing new technology to product will go up significantly. Do you need at least two sources of supply for your parts? What is the cost of bringing your wonderful widget into the company inventory and keeping it there? Is there a spec sheet that actually allows you to achieve repeatable performance out of your innovation? Has a key supplier for your great innovation just been blacklisted for failure to deliver on another project? The questions seem mundane, but without answers the chance of innovation success drops significantly.

Software Innovation

In the opening examples, I compared the CANDU project, which was essentially a construction project, with a series of software projects. Is this a fair comparison or are software (virtual) and hardware (physical) innovation risks fundamentally different? It helps to be clear about what “software innovation” means. The last few decades have seen a number of important innovations in software languages and processes. A recent programming language innovation is Scala. Some say that Agile software development is an innovative process. Great software innovations such as Java or the lesser known Protel, which were both developed by Canadians, can completely revolutionize a market or a generation of programmers and products.

On the other hand, many different things are created using these software languages and processes including user interfaces, databases, real-time operating systems, cloud services, and social media applications. To say that these are all software innovations is the same as saying that any innovation in the physical world is a molecular innovation. Software is what you build virtual things out of. A database innovation does not have much in common with a real-time operating system innovation.

Introducing a new language or software development process into your product development process involves very different time risks than innovating around different types of applications. I have found that the term software innovation is often misleading. When appropriate, it is a good practice to be more precise about what you are developing in software and what aspect of that design is truly innovative.

Over my career, I have been privileged to work on innovation projects in energy systems, manufacturing robotics, telecommunications equipment, semiconductors, eCommerce, and a range of nanotechnologies. At a technical level, I have found each innovation challenge to be unique almost by definition; however, there are some common behaviour and process risks that I have encountered in a variety of circumstances, and I found that those lessons are quite transferable.

Culture and Behaviour

One of the most common time challenges is related to human factors associated with innovation culture. Why is it that people of otherwise unimpeachable character seem to value hopefulness and wishful thinking over honesty and skepticism when it comes to communicating innovation risk to management? I have heard the mantra that “it is better to ask for forgiveness than to ask for permission” in several organizations I have worked in. Perhaps it is the belief, referred to in the introduction, that senior management will double the time estimate you give them and not approve the project. Perhaps the innovator, much like the entrepreneur, is genetically wired to be blindly optimistic. Whatever the reason, I have found that it is a good idea to have several independent time estimates for activities flagged as innovative.

I have already touched on the issue of keeping the invention/creation/discovery activities separate from execution/delivery activities. This need for separation is not simply a question of technology maturity. Appropriate human resource allocation is an important consideration for the innovation project manager. As a way to highlight the cultural and communications differences between the two phases, I refer to this as the "artists and artisans dilemma". In this mental model, artists see what others do not and have the potential to provide you with a masterpiece. You just are not sure when. Artisans will provide you with 300 hand-painted mugs by five o’clock on Friday but may not deal well with the uncertainty of a new design or material. These two personalities are seldom in the same body. When work packets involving invention/creation/discovery end up as part of your execution/delivery plan do you resource it with artists or with artisans? Resourcing is a topic for a different article; however, there are significant time and schedule risk factors associated with the answer.

Internal vs. External Innovation

In a large corporation with a substantial R&D department, new technologies often have a long gestation period before being successfully introduced into a product development process. In my experience, innovative technologies are seldom commercialized in the application that first inspired them. Today, many large corporations are moving away from this type of internal development and are working with a number of external partners to see which one comes up with the best solution, thereby reducing their financial risk associated with technology development. This change in approach requires a different set of risk management tools both on the part of the technology supplier and the customer.

Innovations coming from universities and colleges have their own special time management risks. A large company dedicates considerable resources to working with academic institutions. In the case I am most familiar with, university interaction was to a significant degree a recruitment tool for highly qualified personnel. New employees who had done graduate work on projects sponsored by the company typically reached a level of full performance in half the time that other new graduates would. In those cases where the technology was the principal objective of the engagement, either key personnel from technology development groups were trained to work with universities or, in the case of the more obscure or abstract projects, the technology was first transferred to internal R&D groups. These groups would then bring them to a point where a product or technology group could usefully use them. The iceberg analogy was quite appropriate; the vast majority of the effort expended on bringing the technology to product happened after it was “transferred” to the company even though the university often reported it as “commercialized”.

Today, most companies working with universities and colleges do not have the same internal support system, so it is important to understand where the risks are and what resources are necessary to mitigate them. It is important to expose the academic research groups to your designers, test engineers, and purchasing department early on in the project so that they have some idea of what a final technology outcome will have to look like before it is fit for product. It can also be helpful to establish a personal services contract with the professor to help address a long list of technical issues that are not strictly part of the academic activity.


In summary, to better manage the indeterminate time factors associated with innovation, managers should:

  1. Be clear about the difference between your customer’s innovation experience with your product and the technology innovation that your designers are using to create it.
  2. Identify the specific innovation activities and work packets in your overall product schedule that are new to your organization and flag them for special attention. Ensure that all the stakeholders understand the plan to manage the risks.
  3. To the extent possible, de-risk your innovation inputs before inserting them into your product development schedule. If you cannot do that, ensure you have a contingency plan that will still meet your customer’s expectations.
  4. When evaluating the effort required for innovation input activities involving new technology, make sure you take a broader view of risk evaluation than you do for activities that are part of a well understood process.

Innovation will always entail a certain level of market risk and technical risk; however, good innovation time management practices can significantly improve the probability of success.

Share this article:

Cite this article:

Rate This Content: 
1 votes have been cast, with an average score of 5 stars

Keywords: commercialization, innovation, product development, technology, time management

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.