In this Soft Expert white paper, Paul O’Connor, founder and MD of The Adept Group and Ian Huntly, CEO and MD of Rifle-Shot Performance Holdings, discuss the mistakes to avoid when integrating new product development processes. SoftExpert is exclusively represented in Sub-Saharan Africa by Rifle-Shot Performance Holdings.
As companies experience maturity in some areas of their new product development (NPD) processes or portfolio management, they often begin to recognise gaps in other areas. This is actually good news and a normal part of any organisation’s growth and development. Because each process within the full architecture of NPD has its own sub processes, an organisation’s ability to implement end-to-end process management is dependent upon its ability to understand, integrate, and implement the sub processes.
This recognition comes with maturity. However, if the implementation is not well planned and committed to holistically, organisations tend to face challenges across the business and at various points of the NPD lifecycle. Inversely, with a well-advised approach, the implementation can have profound impact and common mistakes (in particular, the seven identified in this paper) can be corrected or even avoided.
Because the need to develop and enhance process maturity is constant and ever present, what are some of the common mistakes or hurdles management teams might find themselves confronting when integrating sub processes into the full architecture of NPD processes? Here are seven mistakes that commonly occur and some tips to help you avoid or at least address them.
Failure to recognise the front end has different sub processes with different mind-sets and orientations
Most managers recognise that activities, decisions and the general mind-set of people working in the front end of NPD are very different than what it is in the staged development process. But a mistake is commonly made in not recognising the processes within the front end are totally different from each other as well. Road mapping is an independent process from concept generation and both are independent from feasibility assessment. While it serves no good to roll these processes into one monolithic approach, many companies do. Instead, together, these processes must complement one another.
Recourse: Firstly, do not assume senior managers all understand the uniqueness of each sub process and how they all come together in the full architecture. Executive briefings should be orchestrated to share such knowledge in the context of the value proposition of the full architecture. The idea is to share knowledge interactively and in such a way as to complement or add to the currently accepted view of how product development does, and does not, work within the organisation. Here, meaningful diagnostics and assessments can be enormously helpful. This may include one-on-one interviews, surveys, and an analytical break down of past and current product development performance.
Secondly, communicate visually. With processes and process flows, pictures can be worth a thousand words. When communicating with senior management there is usually no need to detail such flows, however, enough detail is needed to demonstrate why they will work. By seeing the processes in relation to one another, you will be giving management a simple way.
Lack of recognition that product line road mapping not only lays out the path for the product line, but it also must generate desirable targets for innovation before moving into the concept generation sub process
Most managers recognise product line road mapping as the act of creating a plan for carrying out the product line over time. But, often such roadmaps or plans fail to create defined targets for innovation, for new technologies, and/or for new creative approaches toward a market. Product line road mapping does not need to generate the final concept, but it should define the desirable targets for innovation. There is a rich history to support the desirability of such targets, both in practical use and in academic research (Crawford, 2011). Failing to set up such targets or, better stated, a portfolio of such targets, is a critical shortcoming. Without these targets there can be little connection between road mapping and concept generation.
Recourse: It is important to introduce and convey an understanding of, and engage the use of a new object into the full architecture: Product Innovation Charters (PICs). PICs are a well thought-out set of new opportunity targets (aka innovation targets) enabling organisations to invest in well-defined and strategically purposeful front-end concept generation activities. The PIC is a key output of smart product line road mapping.
Creating a product line strategy apart from a strong ‘leverage-ability’ platform
Too often, though, product line strategies (in terms of how they will “play out” against the competition) are either non-existent or so weak as to be non-existent. Unfortunately for many businesses, organisational inertia seems to push activities along with only indirect consideration of in-market consequences and competitive reactions.
Recourse: There are good product line strategies and bad product line strategies and many in between. Just because someone has declared a set of actions and/or intentions as a strategy, does not mean it is a good strategy. For most organisations, the first task of product line strategizing is to determine what platforms exist and whether these platforms actually provide sufficient leverage to win against competitors. In fact, the fundamental test as to whether something actually is a platform is to determine if it enables an advantage over the competition, i.e., does it yield leverage? This “leverage-ability” or power of the platform from which new product offerings are created is perhaps the single most important aspect of a product line strategy.
Employing creative thinking only in concept generation and leaving it out of product line strategising, road mapping, and staged development
Creative thought and concept generation go hand-in-hand. But a common mistake is to de-emphasise creativity and over emphasise analytics and analytical thinking throughout other sub processes. For example, within product line strategizing and road mapping, much information and data come into play around such topics as market segmentation, market trends and value chains. An analytical approach to the information and data can be insightful. But much greater value can be realised through creative manipulation of the insights and ingeniously admixing them with other insights derived from product platform and technology analysis. Space, time, and resources need to be carved out for such creative exploration.
Recourse: What makes product development such an exciting and fun area to work in is getting the chance to add value by combing thoughts and interjecting new ideas. Throughout each sub process, activities should be orchestrated so as to encourage and facilitate creative thinking. The good part about designing processes from the ground up is that the organisation can build creativity directly into the process without mandating any specific technique or approach. The advice is simple: make sure each process encourages and facilitates creativity.
Not recognising the advantage of and need for information system support for each process and integrating these systems to make the processes seamless
In the full architecture of product development there are distinctly different sub processes; each with many activities and decision points. At any given time, many projects can be underway within each sub process, with each project at different points toward completion. All too often, organisations fail to understand what is underway and the state of each project. This simple “state awareness” is an early component specific to each sub process. The problem management teams confront is in order to achieve this, earlier maturity level requires real-time information and analytics. The mistake is made when the management team maintains certain sub processes, such as concept generation or road mapping, should be carried out manually. The problem is that a manual approach creates a very steep slope for advancing capabilities.
A variant of this mistake is often made by keeping the sub processes totally isolated from one another, both in terms of organisational process flows and in terms of systems integration and the handoff of “objects” from one sub-process system to another. While disparate and isolated processes may seem easier to establish, implement and manage, the reality is, without integration across all sub processes, each sub process can be at odds with the others and delays between them will greatly devalue the ultimate goal of the full architecture, which is getting the most valuable products to market as quickly as possible.
Recourse: Blueprinting the bespoke systems view of totally integrated sub processes is a notable task. But it is not necessary before the manual creation of the sub processes. What is important, however, is laying out the primary objects across the full architecture, their primary characteristic/fields, and how they relate to one another and to the underlying processes. Consider, at just the highest level for example, such objects as:
• * Product line road mapping initiatives;
• * Product line platforms;
• * Product innovation charters;
• * Product development concepts;
• * Product development projects; and
• * People and their time.
These are the primary objects within the full architecture that need to be managed and facilitated from beginning to end. A purpose-built system needs to do this seamlessly.
Using process-myopic metrics such as time-to-market, where the begin time and end time all take place within a single sub process
Establishing KPIs and tying implicit and explicit rewards and losses to these measures is standard procedure when implementing any process. While a key tenant to KPIs is to keep it simple, a mistake is made if the approach to “keeping it simple” is to silo them within a sub process and/or resist extending them to incorporate a newly introduced sub process.
Recourse: The metrics or KPIs of product development productivity fall into three categories: speed, strategic impact, and resource use efficiency (plus combinations thereof). In the full architecture, measures need to cut across processes. For example, speed or time-to-market needs to reflect the duration from the declaration of a product innovation charter in road mapping to the breakeven point after launch. Similarly, resource use measurement versus output (efficiency) needs to reflect resources used in both–through staged development activities plus front-end road mapping and concept generation.
Limiting who is involved in sub process implementation
Perhaps the most common mistake made by organisations when implementing a sub process is simply to assign a person to the sub process implementation and give that person sole responsibility for pulling it off. The reason this is a mistake is that all processes are cross organisational with unique work flows, decision flows, and information/data flows. To get it right requires the involvement (actual participation measured in man hours) of the people who will use any one of the flows.
Recourse: The big deal in the full architecture of product development is often the decision flow within a sub process will require participation in its design and implementation by top managers – those who will use the decision flow. This is particularly true regarding the linkage between sub processes. For example, it is top management who should make decisions regarding what passes from road mapping to concept generation and from feasibility to staged development. Their thinking needs to be designed into the full architecture and, as such, requires their participation. Our advice is to secure top management’s participation, not just their blessing.