Tutorial Roadmapping for Strategy Support

Transcription

1 Tutorial Roadmapping for Strategy Support by Gerrit Muller Buskerud University Collge and Buskerud University College Abstract Formulating and deploying a strategy requires a combination of vision and analysis. Roadmapping is a tool to explore and articulate future needs and trends for different dimensions, such as the market and customer context, the product portfolio, the technology, competences and supply chain, and processes. Roadmapping helps by relating these different dimensions in time, with a horizon of many years. We will discuss how to create and maintain roadmaps and give practical tips on the format. Copyright c 2010 by Gerrit Muller. Published and used by INCOSE with permission. Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: draft version: 0.1

2 Opening Questions Have you seen roadmaps in your organization? What do you see in these roadmaps? Tutorial Roadmapping for Strategy Support 2 Gerrit Muller version: 0.1 TRSSopeningQuestions

3 Figure of Contents TM customer 1. brainstorm roadmapping Customer Roadmap Business Drivers Policy and Planning Process Technology, Process and People roadmaps Budgets Product roadmap Budget, plan Product Requirements and feedback material presales Requirements and Feedback Product Creation Process sales logisticsproduction service Customer Oriented Process Technical Product Documentation People Technology Process Product related processes People and Technology Management Process Information Order Product $$ Support People Technology Process $$ Key drivers Derived application drivers Requirements 2. Business Processes 3. Key Drivers Safety Effective Flow Smooth Operation Environment Reduce Accident rates Enforce law Improve Emergency Response Reduce delay due to accident Improve average speed Improve total network throughput Optimise road surface Speed up target groups Anticipate on future traffic condition Ensure Traceability Ensure proper alarm handling Ensure system health and fault indication Reduce emissions Early hazard detection with warning and signalling Maintain safe road condition Classify and track dangerous goods vehicles Detect and warn non compliant vehicles Enforce speed compliance Enforce red light compliance Enforce weight compliance Automatic upstream accident detection Weather condition dependent control Automatic counter flow traffic detection De-icing Traffic condition dependent speed control Note: the graph is only partially elaborated for application drivers and requirements drives, requires supports, enables Market Products Technology Process People time, ca 5 years 4. Roadmapping Marketing Architect People and technology manager sales volume Infancy Adolescence Mature Aging 5. Market Product Life Cycle summary time Market Products People Process vision Technology business specific, but open and generic roadmap mission forecasted facts educated scenarios forecasted facts estimates educated scenarios 6. Strategy Tutorial Roadmapping for Strategy Support 3 Gerrit Muller version: 0.1 TRSSlogo

4 Simplified process view customer supplying business strategy process customer oriented (sales, service, production) process value product creation process people, process and technology management process Tutorial Roadmapping for Strategy Support 4 Gerrit Muller version: 0.1 RSPprocessDecomposition

5 Tension between processes customer supplying business strategy process feed back customer oriented short term; cashflow! product creation value mid term; cashflow next year! people, process and technology long term know how (soft) assets Tutorial Roadmapping for Strategy Support 5 Gerrit Muller version: 0.1 RSPprocessDecompositionAnnotated

6 Platform strategy adds one layer supplying business customer strategy customer oriented short term; cashflow! product creation value mid term; cashflow next year! component or platform creation people, process and technology long term assets long term know how (soft) assets Tutorial Roadmapping for Strategy Support 6 Gerrit Muller version: 0.1 RSPprocessDecompositionPlusAnnotated

7 Key Drivers How To by Gerrit Muller Buskerud University College Abstract The notion of business key drivers is introduced and a method is described to link these key drivers to the product specification. Key-drivers Derived application drivers Requirements Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: draft version: 0.2 Early hazard detection Automatic upstream Safety Reduce accident rates with warning and signaling accident detection Enforce law Maintain safe road Weather condition dependent control Improve emergency condition response Traffic speed and Classify and track dangerous density measurement Effective goods vehicles Reduce delay due to accident Flow Cameras Detect and warn Improve average speed noncompliant vehicles Improve total network throughput Enforce speed compliance Optimize road surface Enforce red light compliance Speed up target groups Enforce weight compliance Anticipate on future traffic condition Deicing Smooth Traffic condition Ensure traceability dependent speed control Operation Ensure proper alarm handling Ensure system health and fault indication Environment Reduce emissions Note: the graph is only partially elaborated for application drivers and requirements

8 Example Motorway Management Analysis Key-drivers Derived application drivers Requirements Safety Effective Flow Reduce accident rates Enforce law Improve emergency response Reduce delay due to accident Improve average speed Early hazard detection with warning and signaling Maintain safe road condition Classify and track dangerous goods vehicles Detect and warn noncompliant vehicles Automatic upstream accident detection Weather condition dependent control Traffic speed and density measurement Cameras Smooth Operation Improve total network throughput Optimize road surface Speed up target groups Anticipate on future traffic condition Ensure traceability Ensure proper alarm handling Enforce speed compliance Enforce red light compliance Enforce weight compliance Deicing Traffic condition dependent speed control Environment Ensure system health and fault indication Reduce emissions Note: the graph is only partially elaborated for application drivers and requirements Key Drivers How To 8 Gerrit Muller version: 0.2 COVmotorwayManagementKeyDrivers

9 Method to create Key Driver Graph Define the scope specific. in terms of stakeholder or market segments Acquire and analyze facts extract facts from the product specification and ask why questions about the specification of existing products. Build a graph of relations between drivers and requirements by means of brainstorming and discussions Obtain feedback where requirements may have multiple drivers discuss with customers, observe their reactions Iterate many times increased understanding often triggers the move of issues from driver to requirement or vice versa and rephrasing Key Drivers How To 9 Gerrit Muller version: 0.2 TCAFkeyDriverSubmethod

10 Recommendation for the Definition of Key Drivers Limit the number of key-drivers minimal 3, maximal 6 Don t leave out the obvious key-drivers for instance the well-known main function of the product Use short names, recognized by the customer. Use market-/customer- specific names, no generic names for instance replace ease of use by minimal number of actions for experienced users, or efficiency by integral cost per patient Do not worry about the exact boundary between Customer Objective and Application create clear goal means relations Key Drivers How To 10 Gerrit Muller version: 0.2 TCAFkeyDriverRecommendations

11 Transformation of Key Drivers into Requirements Customer What Customer How Product What Customer objectives Key (Customer) Drivers goal Application Derived Application Drivers means may be skipped or articulated by several intermediate steps Functional Requirements functions interfaces performance figures Key Drivers How To 11 Gerrit Muller version: 0.2 REQfromDriverToRequirement

12 Key Driver Questions What are the key drivers of your customers? Can you quantify these key drivers? Key Drivers How To 12 Gerrit Muller version: 0.2 TRSSkeyDriverQuestions

13 Roadmapping by Gerrit Muller Buskerud University College Abstract This article describes what a roadmap is, how to create and maintain a roadmap, the involvement of the stakeholders, and criteria for the structure of a roadmap. Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: concept version: 2.0 drives, requires supports, enables Customer objectives Application Functional Conceptual Realization Market Products Technology People Process time, ca 5 years Marketing Architect technology, process people manager

14 The Roadmap Integrates Five Views drives, requires supports, enables Customer objectives Application Functional Conceptual Realization Market Products Technology People Process Marketing Architect technology, process people manager time, ca 5 years Roadmapping 14 Gerrit Muller version: 2.0 RSProadmapStructure

15 Granularity of Roadmap Material Top-level roadmap Single page Poster part of many presentations Supporting roadmaps Supporting reports Single page per view or per driver Document per relevant subject Poster part of many presentations Roadmapping 15 Gerrit Muller version: 2.0 ROADdeliverables

16 Problems that Occur without Roadmapping Frequent changes in product policy Late start up of long lead activities, such as people recruitment and process change Diverging activities of teams Missed market opportunities Roadmapping 16 Gerrit Muller version: 2.0 ROADwithoutRoadmapping

17 Management with a Limited Horizon now horizon feature Feature still unknown horizon Do! now feature horizon Stop now feature horizon Do! now feature Roadmapping 17 Gerrit Muller version: 2.0 ROADonOffManagement

18 Management with a Broader Time Perspective now feature Preparation by 0.5 person now feature Work with 1.5 persons legend number of people allocated time now now feature feature Continue with 0.5 person Work with 1.5 persons Roadmapping 18 Gerrit Muller version: 2.0 ROADanalogManagement

19 Creation or Update of Roadmap in Burst Mode Market Market Market Products Collective meeting ca 2 days Products Collective meeting ca 2 days Products Technology Technology Technology Collective meeting ca 2 days Shared Roadmap People People People Process Process Process preparation by expert teams 2 weeks to digest and prepare 2 weeks to digest and prepare Roadmapping 19 Gerrit Muller version: 2.0 ROADbursts

20 Typical Stakeholders of a Roadmap business manager marketing manager(s) overall enterprise responsible discipline or line managers people, process, and technology manager(s) operational manager(s) project or program managers architect(s) Roadmapping 20 Gerrit Muller version: 2.0 ROADstakeholders

21 Target of the First Session Shared vision on market First iteration of possible products as an answer to the market Share technology status, as starting point for technology roadmap Explore people and technology status, to identify main issues Roadmapping 21 Gerrit Muller version: 2.0 ROADburst1Target

22 Target of the Second Session Obtaining a shared vision on the desired technology roadmap Sharing the people and process issues required for the products defined in the first iteration Analyzing a few scenarios for products, technologies, people, and process Roadmapping 22 Gerrit Muller version: 2.0 ROADburst2Target

23 The Roadmap Update Visualized in Time Market: What is needed by the customers? Products: How to package technologies into products to fulfill market needs? Technology: What technological trends are relevant? What technologies are needed? People: What kind of and how many people are required to realize the products and technologies? Process: What processes are required to let these people realize the products and technologies? time Roadmapping 23 Gerrit Muller version: 2.0 ROADsequence

24 From Roadmap to Detailed Plans 201X 201Y Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 roadmap n roadmapping roadmap n + 1 Policy and Planning Process business plan: budget & allocation budget Q1 delta Q2 delta Q3 delta budget Q1 delta detailed planning market events market events Product Creation Process tech hurdle tech hurdle tech hurdle Roadmapping 24 Gerrit Muller version: 2.0 ROADbudgetPlan

25 3-Tier Approach horizon update scope type roadmap 5 years 1 year portfolio vision budget 1 year 3 months program commitment detailed plan 1 mnth-1yr 1 day-1 mnth program or activity control means Roadmapping 25 Gerrit Muller version: 2.0 ROADplanningTiers

26 Roadmap Essentials Selection of most important or relevant issues Key drivers as a means to structure the roadmap Nothing is certain; ambiguity is normal Use facts whenever possible Don t panic in case of impossibilities Roadmapping 26 Gerrit Muller version: 2.0 ROADessentials

27 Requirements for a Good Roadmap Recognizable issues for all stakeholders Clear positioning in time; uncertainty can be visualized The main events (enabling or constraining) must be present Limited amount of information to maintain the overview Roadmapping 27 Gerrit Muller version: 2.0 ROADrequirements

28 Sources of Facts Market analysis reports Installed base number of customers, market size, competition, trends change requests, problem reports, historical data Manufacturing (statistical process control) Suppliers (roadmaps, historical data) Internal reports (technology studies, simulations) statistical process control roadmaps, historical data technology studies, simulations Roadmapping 28 Gerrit Muller version: 2.0 ROADfactSources

29 Causes for Overestimation Quantization effects of small activities (the amount of time is rounded to manweeks/months/years) Uncertainty is translated into margins at every level (module, subsystem, system) Counting activities twice (e.g., in technology development and in product development) Quantization effects of persons/roles (full time project leader, architect, product manager, et cetera per product) Lack of pragmatism (technical ambition is not too bad during the roadmap process, as long as it does not pre-empt a healthy decision) Too many bells and whistles without business or customer value Roadmapping 29 Gerrit Muller version: 2.0 ROADcausesOverestimation

30 Oil and Gas Production Forecast source ASPO 2008 < Roadmapping 30 Gerrit Muller version: 2.0 TRSSoilAndGasProduction

31 Brainstorm Trends Oil and Gas Production Brain storm Trends in oil and gas production social demographic regulatory political economical geographic ecological technical competing energy sources other Roadmapping 31 Gerrit Muller version: 2.0 TRSSbrainstorm

32 Market Product Life Cycle Consequences for Architecting by Gerrit Muller Buskerud University College Abstract The lifecycle of a product category in the market determines many aspects of the architecting approach. The lifecycle consists typical of 4 phases: infancy, adolesence, mature and aging. A discontinuity in market success is seen in the transition from one phase to the next phase. The explanation given is that the phases differ in characterictics and require different approaches. The right approach for one phase is sub optimal for the next phase. A set of characteristics per phase is given and the consequences for architecting are discussed. Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. status: concept version: 1.2 sales volume time Infancy Adolescence Mature Aging

33 Ideal Bathtub Curve sales volume growth stable decline taking shape time Infancy Adolescence Maturity Aging Market Product Life Cycle Consequences for Architecting 33 Gerrit Muller version: 1.2 MPLlifecycleGraphIdeal

34 Market Product Life Cycle Phases in Practice sales volume ideal "bathtub" curve observed curve product unable to make transition time Infancy Adolescence Maturity Aging Market Product Life Cycle Consequences for Architecting 34 Gerrit Muller version: 1.2 MPLlifecycleGraphPractical

35 Examples of Product Classes on the Curve sales volume functional MRI digital TV DVD+RW flat TV MRI scanner DVD X-ray systems VCR TV Infancy Adolescence Maturity Aging time Market Product Life Cycle Consequences for Architecting 35 Gerrit Muller version: 1.2 MPLlifecycleGraphExamples

36 Attributes per Phase Driving factor Value from Infancy Adolescence Mature Ageing Business vision Responsiveness Features Stable business model Refinements / service Harvesting of assets Refining existing assets Requirements Discovery Select strategic Prioritize Low effort high value only Dominant technical concerns Feasibility Scaling Legacy Obsolescence Lack of product knowledge Low effort for obsolete technologies Type of people Inventors & pioneers Few inventors & pioneers "designers" "Engineers" "Maintainers" Process Dominant pattern Chaotic Bureaucratic Budget driven Overdimensioning Conservative expansion Midlife refactoring UI gadgets Market Product Life Cycle Consequences for Architecting 36 Gerrit Muller version: 1.2 MPLattributes

37 From Market, Product, Technology to People, Process Customer objectives Application Functional Conceptual Realization Market Products Technology feedback homework 2002 system actual 2002 electronicsorion Gemini 2002 actual software Orion actual Scorpion Gemini Orion research Scorpion Gemini maintenance research Scorpion total maintenance research estimate total maintenance 22 by program manager total estimate estimate by program by people 133 manager 136 manager estimate by people by program manager manager estimate by people manager People Process after iteration Market Product Life Cycle Consequences for Architecting 37 Gerrit Muller version: 1.2 RSPfromMPTtoPP

38 From roadmap to planning roadmap sharing understanding exploring positioning vision/ambition opportunities broader context consequences plan allocate prepare commit empower milestones sales products people/skills Market Product Life Cycle Consequences for Architecting 38 Gerrit Muller version: 1.2 RSProadmapToPlan

39 Summary of strategy process sharpen vision business specific, but open and generic mission Market Products Technology People Process roadmap input forecasted facts educated scenarios forecasted facts estimates educated scenarios input for focus Gemini actual Q1 Q2 Q3 Q4 k$ sales unit S2, S3 S4 S6 products T1, T4 V6 system committal software electronics mechanics optics 4 plan total fte empowerment context overview reality facts input for next roadmap reality facts Market Product Life Cycle Consequences for Architecting 39 Gerrit Muller version: 1.2 RSPsummary

40 Summary of role in business strategy process roadmap reality facts plan reality facts customer empowerment context, overview empowerment focus, context, overview customer oriented (sales, service, production) process product creation process empowerment context, overview people, process and technology management process Market Product Life Cycle Consequences for Architecting 40 Gerrit Muller version: 1.2 RSPsummaryProcesses