A Process For Designing A Value Chain For A New Product

by Barry Pearson

Previous page | Index | Next page

3. CHECKLISTS FOR COMPARING OPTIONS

3.1 About these checklists

These checklists are tools to achieve appreciation and preferably real consensus, rather than agreement to ambiguous statements. They are completed to the extent that the decision makers believe is useful, whether this is massive detail or few crude numbers.

Each checklist has two dimensions:

Figure 3.1 Dimensions of a checklist

1. A set of attributes, shown vertically, relating to the subject concerned (for example, the attributes of collaboration). The attribute list is a starter-kit, and the enterprise may choose to modify it.
2. The horizontal time dimension, used to ensure that the complete life-cycle is taken into account. This is covered by section 3.2 below.

Here, a very simple life-cycle is used for illustration purposes: “Initial - Release - Beyond”. This should be replaced by a more appropriate version, determined during the “Preparation” phase (section 2.3.1).

3.2 The importance of life cycles

Bakker, Jones and Nichols (1994) refer to the “life cycle of core competences”. Similarly, the lesson from Lorange (1996) is that there is a requirement to actively manage the competences over the life cycle and to ensure that one’s own competences are developed in line with the requirements of this project and of the enterprise.

There also is the theme of a collaboration life-cycle, with the need to achieve the required control of collaborations and providing a safeguard in case of collapse of the collaboration. The Lorange (1996) paper uses the phrase “series of reformulations of the original alliance”.

Various life cycles are possible:

1. Classic product life cycle (introduction, further releases, mid-life boost, withdrawal)
2. Infrastructure life cycle (introduction, modification for new markets, etc)
3. Major capital investment life cycle (as with infrastructure, but potentially with a decommissioning stage - nuclear power station, Brent Spar).

Figure 3.2 Competences needed over a life-cycle

The aim is to ensure that the concerns of all parties are considered - sales (what can we sell this year?), designers (can we continue to develop it?), environmentalists (how can we dispose of it eventually?) Simply arriving at a consensus for the life cycle may be one of the most valuable outcomes of using this Process, and help towards strategic thinking.

The identified life cycle keeps re-occurring, because all decisions must be compatible with it:

1. The value chain needs to be designed over the life cycle of the product/system.
2. The competences also need change over the life-cycle.

(Only those parts of the life cycle for which decisions are needed now need be considered - the Process should not cause paralysis by analysis).

3.3 Cost checklist

This is the checklist referred to by section 2.3.3

Figure 3.3 Checklist for comparing cost options

3.4 Benefit checklist

This is the checklist referred to by section 2.3.4.

Figure 3.4 Checklist for comparing benefit options

3.5 Competence checklist

"Core competence" is not consistently defined. Forbes (1991) states that core competence is the collective learning of the organisation. According to Bakker, Jones and Nichols (1994) core competence emphasises the commonalities of a company's (diversified) businesses. Quinn (1993) talks of managing information about customers, technologies, and distinct knowledge, and uses these in the context of competences.

For the purposes of this Process, I want a further level of categorisation, and I've used the following (derived from part of ICL's OPENframework; an example of the use of OPENframework is shown in Ford and others (1996)):

1. People
2. Process
3. Information
4. Technology

Key questions to be answered are:

1. What competencies are needed for the product/system over its life cycle? What are the "misfits" (Bakker, Jones and Nichols (1994)) or "gaps" (Grønhaug and Nordhaug (1992)).
2. What is strategically important for the enterprise and therefore should be acquired/retained in-house? This should take into account the frequent observation that when competences are frequently used, they often increase in value, and become better developed and managed (Grønhaug and Nordhaug (1992), Bakker, Jones and Nichols (1994)). And as Collis and Montgomery (1995) point out, competences must continually be improved to hold off the decay in their value (for example, imitation).

This checklist is used by various parts of the Process in section 2.

Figure 3.5 Checklist for comparing competence options

3.6 Collaboration checklist

Here, there is no useful difference between the terms "alliance" and "collaboration". The need to judge these over a life cycle follows because over time:

• the product needs will change (because of product and market life-cycles)
• the enterprise will change (because of strategic plans and other forces)
• the collaborators will change (for similar reasons)

Doorley (1993) gives the example of Sony collaborating with, then eventually swallowing, a company which they used as their market entry vehicle. He provides a checklist of eight "Golden Rules" to aid win-win. The first Golden Rule is "plan", and the checklist below is an aid to this. It should also help identify where there is a need to apply some of the other Rules, such as "Identify potential problems early".

Rai, Borah and Ramaprasad (1996) identify critical success factors of strategic alliances, and they include "Partner Congruency" and "Partner Evaluation". The checklist below is intended to play a part in understanding these, especially because of the life-cycle dimension. (Their paper is far too rich to condense into these checklists). One factor that Rai, Borah and Ramaprasad imply is the value of formally tracking an alliance over time. I suggest that a formal "alliance monitoring framework" would be useful, and that using a checklist with initial dimensions of desired attributes versus life-cycle is a starting point.

Eventually, either the initial view of the checklist, or the misfit between original expectations and behaviour over time, may lead to the need for an exit strategy.

This checklist is used by various parts of section 2.

Figure 3.6 Checklist for comparing collaboration options

Competence transfer

Lei (1993) adds an important factor to the dynamics of alliances - competence transfer between the partners. He even classes it as part of the definition of a strategic alliance, while for the purposes of this Process I treat it as not the only factor - the collaborators may be complementary to the extent that there is no value in transfer. But certainly at best the alliance represents a temporary alignment of interests, and Lei provides a useful checklist of the risks and opportunities which ought to reduce complacence.

The checklist below may be useful in helping to map in advance the intentions and risks of transfer over the life-cycle. The competences which may be transferred go far beyond the specification of the product - understanding the fundamental competences which underpin the product over its life-cycle can be an aid to understanding the risks and opportunities of transfer:

Figure 3.7 An approach to examining competence transfer possibilities

3.7 Competition checklist

Prahalad and Hamel (1990) identify that core competence should be difficult to imitate. Collis and Montgomery (1995) also identify the danger of basing a long-term strategy on resources that are imitable, and they provide examples. They point out the need to compare competences with competitors, not just itemise resources. This introduces yet another aspect of a life-cycle dimension - competitors / competition.

This becomes important for the decision criteria "has the enterprise the resources to be and stay leader?" in section 2.3.2. I have not developed this theme much yet.

Figure 3.8 Checklist for thinking about competition

Previous page | Index | Next page