Yay, I can edit my twiki

Here the stuff I wrote so far, if you have too much time on your hands

Utilizing method comparison and creation:

Can a generic product roadmap be made with Software Operation Knowledge as the tool and Method Engineering as the method itself.

Guy Hagemans (ghagemans@cs.uu.nl )

Some notantions: Benefits of implementing roadmapping: Identifying risks and opportunities.

Limitations of roadmapping: Roadmap can lose its power when the situations suddenly changes.

Integrated roadmapping methodology: Among the main motives for a sector association to carry out a road mapping process are the detection, understanding and realization of new business-relevant areas. The integration of experts, customers and users into the roadmapping process minimizes uncertainty in technology development, market introduction and business models. (Erdmann)

Goal of a roadmap: Forecast trend -> develop alternate scenario’s -> backcast?! To the present.

(The practice of product roadmapping borrows heavily from ‘strategic planning and technology forecasting.) (Kappel)

Decision making is increasingly being distributed to business units and their product managers. These business unit managers are closer to real customers and products. Corporate strategists, if they exist at all, often lack influence or contact with those who preside directly over products. (Kappel)

See ‘perspective on roadmaps’ page 2 (picture) for an explanation of the types of roadmaps. (Kappel)

Product roadmaps volgens die paper genoemd in de regel hier boven: product roadmaps articulate a direction and schedule for product evolution to communicate with customers and internal audiences. (Kappel) Also, there is the ‘product technology roadmaps’: Highlight the links between product generations and successive technology generations.  

We believe SOK can improve the local coordination and the schedule of the product innovations. These two goals belong to different roadmaps. A product-technology roadmap presents links between technology and the product, with regard to the generations they have had. A product roadmap is created generally for the articulation of the evolution a certain product will go trough to its customers. The latter relates to the product innovations, the former we believe could be used to improve the local coordination. A practical example is given by Kappel: “A semi-conductor chip manufacturer might create a product roadmap for a given model or to show the evolution of several chip generations in its product family. Its Customer who uses the chips in a system might show the chip evolution as one of several critical components in a product technology roadmap. ” To determine a scope, we should get a more clear view about what a product-technology roadmap and a product roadmap is.

The comparison of the different types of roadmaps is done because the goal is still the improvement of the software product when using a roadmap. Because of this goal, the type of roadmap should not interfere with the assembly of a perfect method of using SOK to improve the product roadmapping and ultimately the product itself. Method fragments of technology roadmaps therefore will be used as a method base when we find it applicable. A Method fragment is a .. Not to mix up things, the technology roadmap method fragments should be extracted with more care. For instance: Garcia et al use the term ‘technology roadmap’ in one of their papers, when they actually refer to a product technology roadmap. According to Garcia et al there is another type of technology roadmap; namely the ‘emerging technology roadmap’. The differences show that this roadmap will not be suitable for any distilling of method fragments;

1. The emerging technology roadmap not only lacks the word ‘product’, but it also lacks the emphasis on the product context. 2. According to Garcia et al : The emerging technology roadmap focuses on (1) forecasting the development and commercialization of a new or emerging technology, (2) the competitive position of a company with respect to that technology, and (3) how the emerging technology and the company’s competitive position will develop.

Because the goal of this research is getting information out of the product using SOK and to generate a product roadmap out of that information, the bulk of the information should come from the (usage of) the application itself. Of course this does not mean information as described above, forecasting new or emerging technologies or determining the competitive position should be excluded, but this is not the focus and therefore is not in our scope.

When determining what activities and deliverables should be used when assembling the roadmap, we should focus on the activities that are at the start of the total process. Here critical decisions are made that will back cast to the whole process (Erdmann)(Garcia) and also the new bits and pieces of using SOK are going to be implemented using ‘method creation’ (Brinkkemper 1998). The following phases were described for the technology (product) roadmap by Garcia et al. • Preliminary activity • Development of Technology roadmap • Follow-up activity

The following key conditions for the preliminary activity were described and found useful: • Input from different perspectives are important to create the willingness of all parties • Therefore support from all ‘stakeholders/parties’ is required

A distinction was made between industry, technology and product roadmaps. When considering a product roadmap, input from the parties that use the software in any way important. This is similar compared to an industry technology roadmap; members from the industry, suppliers and customers should participate when creating the roadmap (Garcia).

The ‘Integrated technology roadmap’ by Erdmann is one of the few roadmaps that explicitly show the inclusion of third parties when constructing the roadmap. They describe an extensive, almost extra, phase of planning where activities are including like search areas, system boundaries, preliminary time frames and socio-economic impacts. The roadmap proposed is focused on technology improvements for a very wide range of roadmaps. Examples are the food industry, railway infrastructure and automotive manufacturing. Although the focus was different, the users of the roadmap remain the same; people. The first phase is important to take into consideration because the main motives to create a roadmap are quite similar, namely ‘integration of experts, customers and users. After an extensive case study of 1 year the conclusion drawn was that the inclusion of experts and users was the main reason for success.

Phaal et al investigated over 40 different roadmaps and revealed the following eight types: “Product planning, service-, capability planning/strategic planning/long range planning/ knowledge asset planning/ program planning./ process planning and integration planning. We believe for a software product company, that delivers multiple applications in the form of software a service- capability planning roadmap would suit the best. This type of roadmap focuses on how the capabilities of an application can be enhanced and supported by new technology. While SOK itself is getting data from the customers, ‘product-technology roadmaps’ are designed to get insights Some roadmaps from http://www.ifm.eng.cam.ac.uk/ctm/trm/documents/published_roadmaps7_6_09.pdf “National grid service roadmap”, 2007: http://spreadsheets.google.com/ccc?key=pk-mNAlXXKxEy1Bvte-g3VA&pli=1 A roadmap towards the collaborative enterprise – CE Vision 2010 http://www.esoce.net/Roadmap%20Summary%20v17.pdf “Enterprise information architecture roadmap”, Louis Rosenthal, 2003. http://www.louisrosenfeld.com/home/bloug_archive/images/EIAroadmap2.pdf

The process of SOK roadmapping The following chapter will propose a roadmap that is tailored specifically to integrate users, experts and other stakeholders. The chapter will be cut down in the following pieces: • The user integration will be supported using Software Operation Knowledge (SOK). After having studied various method fragments, the integration of experts is proposed using method assembly. • A previous study done by Garcia gives various reasons for integrating experts in the roadmapping process. • The integrated roadmap principle proposed by Erdmann

References Bibliografie Erdmann, L., & Behrendt, S. (2006). From Technology-driven roadmapping towards sustainability-oriented roadmapping: Development and application of an integrated method. Seville. Farrukh, C., Phaal, R., & Probert, D. (2004, 1). Technology roadmapping—A planning framework for evolution and revolution. Technological Forecasting and Social Change , pp. 5-26. Kappel, T. (2001, 8 25). Perspectives on roadmaps: how organizations talk about the future. The Journal of Product Innovation Management , pp. 39-50.

Brinkkemper, S., Saeki, M., & Harmsen, F. (1998). Assembly Techniques for Method Engineering. In Advanced Information Systems Engineering (p. 381). Garcia, M.L., Bray, O.H. (1997). Fundamentals of technology roadmapping [Electronic version]. 3-34 accessed 21.02.2007