Apollon - Recommended Toolset and Collaboration Guidelines by European Network of Living Labs

Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level P

Public

Confidential, only for members of the consortium and the Commission Services

Revision History

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Revision Date

Author

Organisation Description

0.1

23.10.2011 HS

AAL

0.2

30.11.2011 HS

AAL

0.4

03.02.2012 HS

AAL

0.5

13.02.2012 HS

AAL

0.7

16.03.3012 HS, MR, AP, MK

AAL, CDT, MAR

0.3

0.6

0.8 0.9 1.0

Summary of APOLLON guidelines, methods and tools

27.01.2012 HS, HH, AAL, SAP, PH, AS, UP8, CDT, CV, ST, BL IBB

20.02.2012 BL, JW, HS 26.03.2012 HS 27.03.2012 HS 08.05.2012 HS

IBBT, SAP, AAL AAL AAL

Editing and additions

Adding detailed methods and tools descriptions in Annex

Adding and editing chapters and completing the structure Editing

Input from WP2; other WP4related tools; editing Revision of Chapter 8 on collaboration Editing Editing

AAL

Final corrections

The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Statement of originality: This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Table of Contents 1.

1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Introduction............................................................................................................... 6 Aim and positioning of this document ...................................................................... 6 APOLLON methodology development mission and scope ................................. 7 Background and wider perspective of APOLLON methodology ...................... 9 Overview of the report ................................................................................................. 11

APOLLON Methodology Requirements ......................................................... 13 Cross-border networking of living labs .................................................................. 13 Pilots as “dual” innovation environments ............................................................. 14 Pilot environments and relation to methodology .............................................. 15 Pilot experiment challenges and methodological requirements .................. 16 From methodology requirements to methodology portfolio ......................... 17 Scenario-based methodology requirement finding ........................................... 18 Scenarios for cross border living labs networking ............................................ 20

Structure of Methodology Framework and Toolbox ................................ 23 Generic and specific elements of the methodology ............................................ 23 “How to” questions for categorizing methods and tools .................................. 23 Fundamental methodology questions .................................................................... 24 Overview of the methodology portfolio ................................................................. 25

Setting Up and Planning Cross-border Living Lab Networks ................ 28

Introduction and overview ......................................................................................... 28 Business plan for a cross-border living lab network ........................................ 32 Cross border living lab network development plan .......................................... 32 Detailed cross border living lab network planning ........................................... 33 Business opportunity identification and analysis .............................................. 34 SME partner search and selection ............................................................................ 35 Business model design for cross border living labs networks ...................... 36 IP-based business models for open Living Labs networks .............................. 38 Consortium contract agreement for collaboration in a living labs network 39 4.10 Profiling of Living Labs and SMEs for finding partners ................................ 40 4.11 IPR handling and knowledge base ....................................................................... 40 4.12 Cross Border Living Lab Partner Contracting .................................................. 41 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

6.1 6.2 6.3 6.4 7.1

Operation of Cross-Border Living Labs Networks .................................... 42 Introduction ..................................................................................................................... 42 Research methods toolbox for cross border living labs ................................... 45 Management of a network of cross border living labs ...................................... 48 Project plan development for cross border living lab networks .................. 49 Planning of innovation projects within a cross border living lab ................. 50 Project management tools and guidelines ............................................................ 51 Collaboration tools in cross-border living labs networks ............................... 51 Performance analysis and evaluation of a living labs network using KPIs 53

Approach to Interoperability and Networking Challenges .................... 54 Common ecosystems facilitating technology transfer to another market 54 Common benchmarking of research for facilitating technology adoption 55 Common technology platform for collaboration in service innovation ..... 56 Common integration framework enabling user participation ...................... 57

Methods, Tools and Guidelines for Specific Cross-Border Issues ........ 59 User interface translation ........................................................................................... 59

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16

8.1 8.2 8.3

Collaboration Practices and Guidelines for Living Labs Networking. 70 Introduction ..................................................................................................................... 70 Analytical framework for collaboration analysis ............................................... 73 Homecare and independent living: collaboration for technology transfer 75 Energy efficiency: cross-border exchange of knowledge and information 82 eManufacturing: a common platform for business innovation ..................... 90 eParticipation: a common service integration framework ............................. 94 Cross-pilot analysis, guidelines and conclusions ............................................. 100

8.4 8.5 8.6 8.7

Value network analysis ................................................................................................ 60 User data benchmarking model for technology testing ................................... 61 Knowledge transfer across cross border living labs ......................................... 62 Investigating user behavior transformation ........................................................ 62 Development of test storylines for user communication................................. 63 Policies and regulations database ............................................................................ 63 Remote guided living labs tour by using webcam technology ....................... 64 Platform for cross border trading of services ...................................................... 64 Software license agreement ................................................................................... 65 Living lab Contracting Framework (1) ............................................................... 65 Living Lab Contracting framework (2) ............................................................... 66 Community reporting tool....................................................................................... 67 Data protection template......................................................................................... 67 Sub-license agreement ............................................................................................. 68 Cross-border application development ............................................................. 68

Foundational Methodologies and Frameworks ....................................... 104

9.1 Research framework for designing and evaluating experiments in Living Labs networks .......................................................................................................................... 104 9.2 Action research framework for implementation of the living lab network 106 9.3 Cross border Living Lab network Pilot development and implementation 107 9.4 Socio-technical change, actor network theory and related frameworks 107 9.5 Methodologies for networks of living labs ......................................................... 108 9.6 Creating and operating collaborative and networked organizations ...... 108

10.

Knowledge Center .............................................................................................. 110

10.1 10.2

Background................................................................................................................ 110 APOLLON contributions ........................................................................................ 110

Annex 1: References and Other Sources ................................................................ 111 1. 2.

Literature ....................................................................................................................... 111 Internet sources ........................................................................................................... 112

Annex 2: Detailed Descriptions of Selected Methods, Tools and Guidelines .............................................................................................................................................. 113 1. 2. 3. 4. 5. 6. 7. 8.

Cross Border Living Lab Partner Contract Template ..................................... 115 Basic contract between test-users and Living Lab .......................................... 122 Business Model Design for Cross Border Living Labs Networks ................ 130 Policies and Regulations Database ....................................................................... 142 Contacting and Profiling Platform on Knowledge Center ............................. 148 Framework for Value Analysis ............................................................................... 154 Requirements Analysis.............................................................................................. 158 Decision and Management Support Framework ............................................. 163

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

Project Plan Development for a Cross Border Living Labs Network ........ 175 Cross-Border Knowledge Sharing ......................................................................... 194 Observation Data Collection and Focus Groups ............................................... 196 Collaboration and Communication Tools ........................................................... 200 Project Meeting ............................................................................................................ 204 Cross-Border Application Development Framework ..................................... 206 Community Reporting Tool ..................................................................................... 213 Platform for Cross Border Trading of Services................................................. 218 Remote Guided Living Labs Tour Using Webcam and Web-conferencing 222 Test Storyline for user communication ............................................................... 226 Designing Use Transformation Processes .......................................................... 229 Checklist to prepare for product or service introduction ............................ 235 Checklist to implement a use case in another environment ........................ 237 Customer review questionnaire ............................................................................ 241 Expertise database ...................................................................................................... 242

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

1. Introduction 1.1 Aim and positioning of this document This deliverable D1.4 presents a “Recommended Toolset and Collaboration Guidelines” which is the concretization of the “APOLLON Methodology”. This APOLLON methodology is understood as a comprehensive and coherent set of guidelines, methods, tools and procedures for supporting the inception, planning and operation of cross-border networks of living labs. The mission of the cross border living labs networks is to support SMEs in carrying out activities regarding collaborative research, development and innovation as well as market creation. The structure of the methodology is presented in terms of a set of “how to” questions: “how to” set up, plan and run a cross border network of living labs for the purpose of carrying out joint research, innovation and market creation activities. To these practice oriented questions we add more theoretical and “foundational” questions focusing on understanding the principles and foundations of the methodologies. Referring to the APOLLON Description of Work, within this D1.4 report the following partial results are presented 1: •

•

A set of methods, tools and guidelines enabling sustainable collaboration for research, development, innovation and market development in settings of cross-border living lab networks.

Guidelines for collaboration among the partners of a cross border living labs network, addressing the different challenges covered in the domain specific pilot experiments.

A platform for knowledge sharing and network level services for vertical and horizontal domains within the APOLLON project and related stakeholders. A platform for methodology support is offered through the “Knowledge Centre” (http://knowledgecenter.openlivinglabs.eu/). This portal contains a repository of recommended tools, guidelines and practices which will be continued after the lifetime of APOLLON 2.

D1.4 thus presents the supporting tools, recommendations and guidelines from a “normative”, “prescriptive” perspective, much like a “handbook”. We go beyond what was experimented, used and validated within the four pilots, and add information, knowledge and insights that are considered to be valuable in these and comparable situations. This way the D1.4 is complementary to the D1.5 deliverable, which presents the empirically validated methodology for cross border living lab activities within networks of Living Labs, addressing the interoperability challenges in cross-border Living Labs networks. Whereas D1.4 represents a merely “top down” approach, only shortly commenting on 1

The formulation of results is adapted from the APOLLON Description of Work for D1.4. The “network level services” are represented by the Domain Networks (WP6).

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

experiences within the pilots, D1.5 is “bottom up”. Both D1.4 and D1.5 build on the D1.2 Research Framework and Investigation Strategy.

The set of concrete tools, guidelines and governance principles presented in this D1.4 and the methodology for conducting cross-border pilots and experiments in and by a network of Living Labs in D1.5 are part of the over-all APOLLON methodology framework following the four phases of connect, plan and engage, support and govern, and manage and track introduced in the D1.2, and which is summarized in this D1.4. Conducting the cross border pilots has continuously enhanced our insights in which methods, tools and guidelines are appropriate.

1.2 APOLLON methodology development mission and scope

The over-all role of the methodology work in APOLLON is to develop, introduce and validate a practical methodology and toolsets for: • •

Setting up, planning, operating and managing cross-border network of living labs to support SMEs in their innovation and market development objectives;

Supporting collaboration within cross-border networks of living labs for the purpose of SME innovation and market development.

The APOLLON methodology aims to be generically applicable, and consists of a coherent set of concepts, processes, methods, tools and guidelines. Methodology development does not precede the actual living lab network experiments, but goes hand in hand with these actual pilot experimentations. This implies that the value of the methodology for support of cross-border collaboration has been demonstrated during the actual pilot experiments as much as possible.

APOLLON conducts four experiments in four different thematic areas to create, run and evaluate such cross-border living lab networks. Each of the four experiments explores a particular category of “harmonisation and interoperability” challenges 3. These four challenges focus on establishing four different sets of enabling conditions for successful collaboration within the living labs network: • • • •

A common ecosystem approach is experimented in the Homecare and Independent Living pilot.

A common research benchmarking approach is experimented in the Energy Efficiency pilot.

A common technology platform approach is experimented in the eManufacturing pilot.

A common integration framework is experimented in the eParticipation pilot.

Methodology development must address “harmonization” and “interoperability” issues that are relevant to particular cross-border contexts of the domain specific living labs networks. Traditional “single” living labs operate in a local or regional context of actors and their innovation needs. APOLLON introduces the notion of a network of collaborating living labs, where living labs assume the role of “gatekeeper” and “gateway”, and this concept is experimented in the four pilots. 3

These four “harmonisation and interoperability challenges” and the respective pilots are explained in detail in the APOLLON Description of Work.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Mission and Scope of APOLLON Methodology & Tools development (DoW) APOLLON creates a methodology for setting up cross border networks of living labs, an approach to apply and validate the methodology, a framework to measure success of the methodology. APOLLON methodology work addresses how living labs platforms or resources can be shared among thematic cross/border networks of living labs. It will address how to find synergies between the actors, scale up lead markets, facilitate strategic partnerships, orchestrate systematic RDI processes, stimulate cross border innovation APOLLON methodology work will help solving interoperability challenges in cross/border living labs networks on different levels: to what extent may a common platform or technology help solving this challenge, to what extent should the ecosystems of each living lab be comparable, to what extent are common tools and techniques required for cross border networks. APOLLON delivers a set of validated methodologies to set up and conduct cross border living lab pilot networks. The use of such a common approach within the cross border networks of living labs will enable stakeholders to set up, carry out and transfer projects faster, easier and more efficiently. APOLLON delivers a recommended toolset for facilitating cross-border research and innovation. Methodology work identifies the basic principles, concepts and processes that underlie cross-border domain specific networks of living labs. Cross border living lab network methodology acts as a framework and includes the creation of action-based and value adding strategies and concepts for cooperation, tools and methods to stimulate user involvement, user empowerment to enable true collaboration, best practices and lessons learned to be used as guidelines, harmonisations between the different living lab methods and approaches to better understand and assess the benefit, and contextual impact factors. APOLLON aims at defining and harmonizing tools and platforms for the set up and successful operation of such a network. It also implies generating an impact assessment framework that can be used to benchmark and validate such approaches. Methodology work acts “horizontal”: methodology will be created based on current state of the art and inputs from vertical experiments. Methodology will be presented as a framework with a set of tools and processes for any groups that wish to set up and conduct cross border living labs networks. APOLLON methodology will address interoperability challenges in cross-border living labs networks through different levels. Technological (to what extent a common platform or technology will help solving these interoperability challenges), organizational and regulatory policy (to what extent should ecosystems be comparable), research (to what extent are common tools and techniques required for cross-border networks). As APOLLON takes a service perspective, emphasis is on services the living labs networks can provide to their stakeholders. APOLLON will develop a set of guidelines and processes that can further stimulate cross border collaboration.

APOLLON proposes the notion of a Domain Network, consisting of actors in a thematic domain (e.g. homecare, or manufacturing). A Domain Network acts as a thematic community and as a “breeding ground” of ideas and projects. As such the Domain Network may eventually result into a concrete project which is constituted by a collaboration between living labs and other participants such as SME’s, large companies, research entities, innovation intermediaries and municipalities. The Domain Network forms the breeding ground of focused collaborative project networks. Such collaborative project network must be able to easily search and connect different actors, different local ecosystems, different ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

business processes and work methods, and different technical platforms. In order to create and run a successful cross-border project network, interoperability and interworking of all elements mentioned is necessary. Therefore, the issues that need to be taken into account include the comparability and interworking or integration of local ecosystems and the use and interworking of common platforms or technologies. APOLLON methodology also addresses more fundamental issues, aiming for understanding rather than practical tools. For example how design science related research frameworks can be used to structure cross border living labs pilots; or how to develop, apply, evaluate and validate a living labs innovation methodology within a cross border pilot environment as an “action research” activity. Methodology development also addresses the way how knowledge resources can be made available and accessible, to benefit existing or new partner networks. Finally, methodology development addresses collaboration and interaction processes between methodology developers and vertical experimenters to support knowledge sharing and interaction. Some of these “foundational” issues are considered in Chapter 9.

Partly APOLLON project objectives are realized within the context of vertical pilots on cross-border living labs networks. The activities within these pilots aim to set up, build, run and evaluate “experiments” on cross border living labs networks. These experiments aim to demonstrate the feasibility and opportunities of cross border living labs networking in pilots. At the same time the pilots investigate the factors and conditions which are affecting the outcomes, and methodology has supported this. In each pilot a specific challenge regarding harmonisation and interoperability, which must be overcome in order to realize the cross border network of living labs, stands central. Given the objectives of the vertical pilots, both methodology work and implementation of vertical experiments should strongly interact. Therefore a loose coordination mechanism has been established to guide and optimize these interactions, in the form of liaisons between methodology and piloting. Eventually, APOLLON Methodology and its set of Recommended Tools and Guidelines aims to support new initiatives to develop, create and run crossborder networks of living labs. The methodology therefore will need to be generalized, and also needs to be made accessible for interested parties outside APOLLON. For this purpose, the Knowledge Center (http://knowledgecenter.openlivinglabs.eu) has been established. The wider mission of the methodology work within APOLLON is summarized in the box above.

1.3 Background and wider perspective of APOLLON methodology

Over the last 5 years there has been an increasing number of Living Labs throughout Europe, which are gradually forming a vibrant and still growing community. These Living Labs do not only differ in the composition and approach but also in the domains they address. Several Living Lab networks have been set up on European, national, and regional levels which so far mainly exchange high-level principles and best practices for individual Living Lab set-up and implementation. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Earlier APOLLON D1.1 State of the art living labs methodologies has shown that the exchange of best practices and lessons learned is seen as the most important goal of a collaborative Living Labs network, followed by harmonizing and integrating tools and methods between the partners. A third objective is to perform joint research and innovation activities. The aim is that between partners of the various Living labs and over the border of each Living Lab, research and innovation activities on a larger scale can be set-up and executed.

To this the APOLLON project adds the over-all objective of creating a methodology for setting up and conducting cross-border innovation and market development activities. To achieve these objectives, guidelines and tools must be developed to: • • •

•

Connect: opening up opportunities for joint research, innovation and market development, and bringing together potential partners for collaboration; Plan and engage: defining the roles of the partners, negotiating responsibilities.

Support and govern: executing joint research innovation and market development activities, based on the harmonisation and integration of tools and methods applied by the partners Manage and track: managing the joint research and innovation activities, including the exchange of information between partners and initiatives

Providing a practical, useful set of support tools, methods and guidelines for organisations and networks of living labs is the main topic of this deliverable.

The wider ambition and perspective of APOLLON methodology work is to establish and make accessible to others a more stable and sustainable methodology framework and toolbox. A sustainable methodology framework and toolbox infrastructure is a prerequisite for stimulating and accelerating user driven and open innovation across networks of innovation environments. Availability of methods, processes and tools that support open innovation is expected to enable and stimulate interactions, co-creation and feedback in those cross-border networks, and will empower users through co-creation processes, which in turn will push for social, economic and institutional transformations. The target is to contribute to an open, creative and networked innovation environment where ideas and knowledge move freely, and where collaborative innovations and SMEs international market development rapidly comes off the ground.

Within the methodology development work of APOLLON and other living labs projects, demand has emerged for a “Living Lab RDI Toolbox”: a knowledge base of the various methodologies, procedures and ICT-enabled tools and techniques for conducting empirical human-centric RDI work. Such methods, techniques and tools are highly relevant for Living Labs operations and may include: •

Web based tools and platforms that provide companies and organisations with a controlled environment for collecting data, as well as for managing user communities and projects involving large-scale user communities;

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

• • • •

Tools and an environment for initiating, planning, managing and reporting projects and project data; including support for multiple consecutive projects; Tools and an environment for gathering findings and recommendations throughout the project run, as well as, a centralised action database for managing all project findings;

Tools for maintaining and updating target group user databases for different types of consumer recruitment organizations; Tools for recruiting consumers from own or partner’s target group user databases; Tools for maintaining and managing testing facilities including video streaming and annotation support;

Environment for consumers and testing projects to come together and discuss the research online (user community).

In order to effectively use such tools, the supporting functionalities and processes must be in place, including governance arrangements, user engagement processes, knowledge management principles etc. Whereas this goes beyond the concrete objectives of APOLLON, which is dedicated to support cross-border collaboration for innovation and market access as based on the pilots mentioned, this deliverable describes some of the mentioned tools, techniques and processes as far as they were developed and experimented within the APOLLON project. For the near future, the Knowledge Center may provide the portal to ensure access to a wider collection of methods and tools.

1.4 Overview of the report

Chapter 2 formulates the requirements and demands to the methodology, based on the characteristics of the pilot environments. For this purpose, it introduces a layered set of “how to” questions as basis for elaborating the methods and tools. Chapter 3 provides the structure and over-all overview of the methodology framework. This is based on further elaboration of the “how to” questions.

Next chapters 4-7 elaborate the different methodology elements. Methodologies for setting up and planning cross border networks of living labs are covered in Chapter 4. The operation of the living lab network for research, innovation and market creation is addressed in chapter 5. Central networking and interoperability challenges are covered in chapter 6, whereas methods and tools dedicated to specific issues and problems are presented in chapter 7. In chapter 8 we look more horizontally into the fundamental issue of “collaboration”. Based on analysing collaboration structures and processes within the pilots, we propose guidelines for collaboration in cross border living labs networks. The Chapter 9 covers foundational aspects of cross-border living labs methodologies.

Finally, Chapter 10 presents a concise overview of the Knowledge Center portal, which stores many of the methodology elements presented.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The Annex 1 provides references and Internet sources, whereas Annex 2 presents more detailed descriptions of the methodology elements proposed in this report.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

2. APOLLON Methodology Requirements This chapter elaborates the initial demands and requirements to APOLLON methodology based on understanding the objectives of the four piloting environments and of the role methodology elements are playing in these pilots.

2.1 Cross-border networking of living labs

There exist already several collections of methods and tools to support single living labs innovation processes, based on various single Living Lab projects. The overview presented here focuses on networks of multiple collaborating living labs and SMEs, and especially on supporting the cross-border collaboration between these living labs. However, other methods than explicitly addressing cross border issues are added here as well, since these methods, even if they are not specific to the cross border situation, are of high value in such cross border settings. For reasons of completeness, a comprehensive set of methods and tools is presented. The specific cross border aspects of setting up, operating and managing living labs networks and cross border aspects of innovation and market creation arise because of the existence of differences: •

•

Differences in cultures and practices of human and organizational collaboration, and related aspects of decision making, design traditions etc. which affects processes of collaborative innovation and market creation, and collaboration in general, and requires efforts to enhance trust and understanding, create common organizational approaches and common visions.

Differences in business ecosystems or value networks: different actor roles, responsibilities, organizations, which requires finding appropriate partners and ensuring that roles and responsibilities are met.

Different local and national rules and regulations, e.g. the existence of different regulatory and competition frameworks in healthcare and energy sectors across countries, or different frameworks for IPR and contracting, which requires the modification or adaptation of these frameworks.

Differences in technical systems, requiring interoperability, standards and local adaptation of systems to user environments.

The existence of these differences encourages us to think more fundamentally about methods and guidelines to overcome such differences. As Table 2-1 illustrates, these methods and guidelines can be of a very different nature.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Cross border issues Different cultures and practices of humans and organizations Different business ecosystems and value networks Different regulatory systems and rules Different technical systems and infrastructure

Overcoming cross-border issues to connect and interoperate in cross border living labs networks This is relevant where different living labs are working together for example on joint development and testing. Here we need to address the behavior and understanding between people and the alignment of work processes and project management.

This is relevant where living labs work together and also where technologies are transferred into another market. Success conditions of adopting technology solutions must be understood and besides technical adaptations, in new markets the roles and responsibilities of actors should be fulfilled.

Such different regulatory systems may hinder the transfer of technology solutions to another market. Technology solutions must be adapted and be adaptable to the local market conditions. Different applications and platforms may need to interoperate to enable seamless collaboration across boundaries. Technologies, systems or services may need specific adaptations and interfaces to be useful in another market.

Table 2-1: Differences in cross-border environments and how to overcome them

2.2 Pilots as “dual” innovation environments Point of departure for APOLLON methodology development lies in the four designated “vertical” piloting environments, where the building up and running a cross border living labs network is experimented under different contextual conditions. Two “dual”, intertwined innovation cycles should be distinguished. First, the vertical pilot environments are preparing and running the living lab cross border network, to demonstrate that the cross border living labs network is a feasible, realistic and valuable concept. In doing so, these piloting environments are also investigating the different contextual factors that affect the success of cross border living labs networking, as well as how to address specific harmonization and interoperability challenges. Second, and for the issue of methodology development highly important, the pilot environments act as environments where APOLLON methodology itself is developed, introduced, used and validated. Vertical pilot environments act as environments of demonstrating cross border living labs networking ánd methodology development. They aim to: • •

Set up and build cross border living labs and demonstrate their value; investigate contextual, situational factors and challenges affecting success or failure Develop, tailor, adopt and use, evaluate and validate methodologies for creating and operating the living lab cooperative network.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

2.3 Pilot environments and relation to methodology APOLLON explores the concept of cross border collaboration of living labs in four complementary pilots that experiment different challenges of living labs networking for SME research and innovation support. In summary: •

•

Homecare and independent living: common ecosystems. Existing homecare solution piloted in one local living lab is transferred to another living lab, cross-border. The key issue studied is what kind of ecosystem, value network, common approach will be necessary to establish successful cross-border living labs collaboration network. Energy efficiency: common benchmark. Smart metering solutions affecting use behavior are experimented and validated in different user environments. Information and knowledge is shared across these environments. The key issue is how innovation activities in such environments may result into behavioral change and may support SMEs and living labs to develop and test effective energy management solutions and business models (e.g. adapted to local regulations). How can we utilize the generated information and knowledge, and how can we enhance the scalability of this living lab networking approach. eManufacturing: common technology platform. A common technology platform is piloted in each of the local living labs in the cross border network. This approach aims to facilitate cross border collaboration of SMEs and living labs, to support SMEs in using common services and resources, and to facilitate new forms of collaboration. eParticipation: common service integration framework. A service integration framework is being experimented to enable the integration of locally tested service components into each of the living labs in the cross border network, in order to build integrated solutions. The integrated solutions are being deployed in the different living labs in the network, to test the solution in different contexts.

The “horizontal” methodology development’s role is to support the development, application and evaluation or validation of methods and tools that can be used to build up, run and evaluate a cross border living lab network. Methodology development brings in concepts, ideas, guidelines and methods and tools. Methodology development also gathers methods and tools that are being developed and validated in the “vertical” pilot experiments and generalizes them for wider application. In this sense methodology development and vertical pilots are interacting (top down and bottom up, push and pull). In the end, methodology development generalizes towards a “how to” collection of methods, tools and guidelines on basis of results of work carried out within the vertical pilots and based on concepts and methods already available or initiated by the methodology task group. The Apollon vertical pilots are organized in four key activities: 1. Experiment preparation, 2. Experiment setup, 3. Cross-border piloting, 4. Evaluation and recommendations. Methodology work closely interacts with vertical pilots in particular on 4. Evaluation and recommendations where an evaluation framework is provided and where support is offered in applying the evaluation framework. Methodology work and pilots also work together to propose ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

methods and tools addressing the particular pilot context and to support the pilots experimental work to develop and validate these methods and tools.

2.4 Pilot experiment challenges and methodological requirements

For the purpose of methodology and tools development within Apollon, and generalization and transfer of methodology and tools for new cases, the particular challenges addressed in the vertical pilots must be understood as these challenges imply requirements to the methodology development. Of particular importance to methodology development are the networking and interoperability challenges.

Mission and challenges of vertical pilots (based on Apollon Description of Work) • •

•

General objective. To pilot and validate how cross border collaboration of living labs leads to measurable improvements in innovation and to sustainable networks. To validate the added value of cross border networks. Challenges for networks of living labs. Different challenges are identified that need to be overcome. Among these challenges are interoperability (at different levels: technology, user selection, value networks etc), methodology (shared methodology), contextual requirements (requirements regarding regulations and markets, supply chains), ecosystem rules and roles (how to create functioning ecosystems) etc Interoperability and networking. Each pilot focuses on a specific harmonization and networking aspect: common ecosystem, common benchmark framework, common technology platform, common integration framework. Each experiment investigates solutions for these aspects which enhance cross-border living labs networking and collaboration. Example homecare and independent living. This experiment addressed the ecosystem related issues, including contextual factors, business models and (organizational and service related) interoperability. A framework is created that identifies these factors on the level of usage, social and cultural differences, legal and regulatory aspects, as well as ecosystem determinants. The experiment generates protocols that help in efficient and effective planning of transposing homecare and independent living care systems from one country to another. Example energy efficiency. This experiment creates a network of living labs that address common challenges related to regulatory issues in the free last energy mile market. It demonstrates energy saving and local energy production at city level. Develops new value constructions and business models through these pilots. Highlights regulatory issues. Develops a common benchmark framework which enables comparability of research data within cross border projects

Based on an understanding of the pilots challenges and situational characteristics, the main issues covered in the pilots are depicted in Table 2-2. Each pilot experiment covers a different innovation, is based on a different living labs networking scenario, addresses different interoperability and networking challenges and structures their piloting experiments differently. Table 2-2: Vertical pilots characterization and demands to methodology

Technological innovation

Homecare and independent living

Energy efficiency

eManufacturing

eParticipation

Remote gateway and sensor-based systems

Smart metering

Integration and service platform

Content aggregation and open platforms

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Living labs cross- border networking scenario

An existing solution, piloted in one living lab, is transferred to another living lab in another country

Different projects are experimenting on smart metering technologies and how these will impact energy behavioral change

Different Living labs are using a common technology platform to facilitate collaboration, and initiate new forms of collaboration

Locally tested applications are integrated into integrated solutions, which are tested in the local living labs

Experiment context

Evaluation of services in another market. Investigate different contextual factors, understand specific market structuresâ&#x20AC;Ś to assess the need and requirements of common eco-systems

How can pilots results be transferred from one to another living lab (impact of real time data on the energy consumers behavior). How can a benchmark approach make pilot results comparable.

Integrated services are piloted in each of three living labs

Type of experiment outcomes

Lessons learned with regard to the experiments itself, guidelines, methods and tools for conducting cross border living lab projects. Insight in what kind of ecosystem, value network, common approach needs to be in place in a domain specific network of Living Labs

Platform deployment and making it available for living labs and local SMEs Assess how the platform can address the challenge of providing a common collaboration framework, and how it helps SMEs to set up cross border activities Insight in factors and conditions that result in a successful common platform which enhances collaboration.

Insight to what extent an integration framework can facilitate cross border research between different stakeholders; insight to what extent the approach can be used to scale-up existing projects and to explore new markets

How can a common platform be used for joint service innovation How can new forms of collaboration be facilitated by the common platform.

How Living Labs can help testing the integration of technologies developed What needs to be adapted to test the interoperability of technologies in different local settings

Harmonisation and networking challenges that need to be addressed in the experiment

Points of attention to Methodology development

Building a common ecosystem, value network and common approach Protocols for efficient and effective planning and deployment of transposition

What is the required ecosystem, value network, approach for setting up cross border experiments Define and identify roles and stakeholders within the required eco-system for cross-border pilots How may common ecosystem building benefit cross-border living lab innovation

Building a common benchmark framework that will be deployed in all living labs in the network Scalability of the living lab network, its services, and comparability of research data within cross-border projects

A benchmark framework that enables steering of local research activities to compare different results and experiment with successful outcomes of one living lab in another.

How can research data e.g. user behaviour be compared across living labs in a network How can the living lab network and its services be scaled up, based on such benchmarking

Building and using a common technology platform, and common collaboration framework

Building an integrated framework enabling the integration of services

2.5 From methodology requirements to methodology portfolio Based on the pilot experiment descriptions, the different methodology and tool elements that are found to be important can be identified in some more detail. Table 2-3 presents these elements in a matrix of methodologies and tools versus pilots. Some of these methodology elements are common among multiple vertical experiments. Table 2-3: Main methodology topics in the four vertical pilot environments Methodology and tools topics covered in pilots

Homecare and independent living

ICT PSP Project Reporting

Energy efficiency

eManufacturing

eParticipation

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Project planning and preparation main focus

Planning the crossborder transfer of technology solutions

Legal and regulatory constraints in cross border innovation

Different regulations in homecare services in different countries

Introduction and adoption strategies

Identify and cope with social and cultural differences , involve the stakeholders

Local ecosystem adaptation to cross border requirements

Definition of actors and roles in different contexts, creating local ecosystems

Planning comparative evaluation of experiments based on benchmarking

Different regulations in the energy markets

Planning the different use cases as “technical” projects Not covered

Planning the different experiments in the pilot

Legal issues and IPR protection

Not covered

Adapting of service to local specifications

Not covered

Using the available MDI platform

Benchmarking of testing data generated by experiments in the pilot

Transferring the research set-up and results of previous local pilots to the other Living Labs

Ensuring comparability of energy usage data in different smart metering projects

Integration of software components

User involvement and empowerment

Engage users for experimenting with local adaptation of care solutions

Involve households and citizens for energy saving approaches

Technical systems interoperability

Business models for cooperation in the living labs network

Tools for supporting cross-border collaboration Evaluation of pilots in terms of impacts and value added Living lab methods adapted for cross border projects

Adapt business models for homecare solutions to different contexts

Tools to support communication and collaborative working

KPI-based evaluation framework

Creating a pilot based ad-hoc eco-system to conduct the crossborder experiment

identify value networks and business models in the energy market

Knowledge exchange instruments KPI-based evaluation framework Managing user interaction across different experiment settings

Not covered

Business models for common use of services or components

Business models for integrating software into applications

Common technology platform

Not covered

Communication tools KPI-based evaluation framework Not covered

Evaluation of crossborder acceptability and user experience

KPI-based evaluation framework Application development framework based on agile development

One of the challenges in developing a generalized methodology portfolio is to develop an appropriate classification of the methods and tools and describing them in such a way that common elements across the experiments can be identified, and generic elements can be distinguished from specific elements. Such a classification eventually will link to the sets of “how to” questions proposed in next Chapter 3 as a foundation for methodology development.

2.6 Scenario-based methodology requirement finding

Within APOLLON, scenarios are not considered in the usual way of describing a possible, often extreme, future situation under uncertainty, for the purpose of stretching our minds to generate new solutions. Rather, APOLLON scenarios represent high-level storyline description of the actions, situations and ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

processes that together constitute the creation of the cross-border living lab and its networking and collaboration in action. •

•

Actions: setting up and operating a cross border living lab network can be characterized by high-level sequences of activities or situations, driven by SME’s and living labs needs. Example actions are: analyzing a business opportunity, finding a partner, establishing the living lab collaboration infrastructure, creating the RDI environment, coordinating the innovation project, collaborating on testing of solutions. Patterns of actions will differ across the pilots. Situations: here we focus on the cross border collaborative situation during joint research and innovation. An example is a collaboration situation where SMEs and living labs interact concerning a design and development process. Situations might be connected to the actions defined above, for example an “action” can be considered as going from one to another “collaborative situation”. Processes: at a more specific level within the steps and / or situations we identify underlying processes that might need tools support e.g. information sharing, collaborative testing, user involvement management, collaboration coordination, search for partnering, co-designing.

Fig. 2-1 Initial cross-border living lab scenario

Elaborating the scenario has the role to clarify the methodology requirements. Fig. 2-1 provides an initial scenario at the level of “actions”. This scenario illustrates a storyline sequence of actions including business opportunity identification, contacting living labs, matchmaking with crossborder living labs, project scoping, stakeholder identification and agreement finding, project management, market introduction analysis, and evaluation. This basic scenario has adapted and more elaborated versions for each of the four pilot environments.

In the preparatory phase of defining and setting up a cross border living labs network, the development of a scenario description of actions, situations and processes will help selecting the appropriate methods and tools. Comparative analysis of the different scenarios will enable us to identify “common’ guidelines, methods and tools that are relevant in multiple although still different situations. This is important for our aim to generalize methodology elements for completely ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

new situations. The following section provides an overview of processes or interactions that constitute the scenario for the particular experiment.

2.7 Scenarios for cross border living labs networking

As indicated, the vertical pilots can be described in terms of major actions, situations and processes that need support by guidelines, methods and tools, procedures. We are now interested in generalized descriptions as a basis for a generalized APOLLON methodology development.

The Homecare and independent living scenario departs from the SMEtriggered transfer process of a homecare technology solution piloted in one living lab to another living lab in another country. The SME contacts the living lab (e.g. the living lab in their home country) in order to facilitate the development of a new market. The scenario includes the various steps to establish the collaboration and complete the transfer process including identifying the required eco-system, finding the required and appropriate partners, testing of the solution, and thus defines various situations of living lab collaboration and networking e.g. The scenario enables us to identify the underlying conditions to be established e.g. creating the local ecosystem, planning the transfer process, and developing an appropriate business model.

The energy efficiency scenario describes a constellation of different living labs in different countries experimenting a technology solution for energy efficiency and sharing the real-time data on the consumers generated in experiments. The living labs exchange the pilot data based on a benchmarking framework, in order to stimulate behavioral transformation leading to energy saving. SMEâ&#x20AC;&#x2122;s are supported by the living labs to enhance and test their smart metering solutions and to explore new markets. The scenario describes several types of crossborder activities such as business matching & partnerships creation, technology testing, and knowledge transfer. The eManufacturing scenario is based on living labs of which each host a number of SMEs. An SME develops and provides a service, e.g. to monitor energy consumption in a manufacturing plant. This service could then be consumed by another SME hosted within a Living Lab in another country and could finally be used by end users to monitor their energy needs. The eParticipation scenario (see Box) describes a series of complementary SMESâ&#x20AC;&#x2122;s technologies coming together to pilot an integrated technological solution that matches the needs of a public body (e.g. local city councils, municipal innovation agencies, municipal museums). Details of the eParticipation scenario

The scenario included three actors: 1) one (or more) SME willing to export its technology abroad and ready to collaborate with international partners; 2) a public body willing to experiment a foreign technology; 3) a living lab is that helps identifying the opportunities, analyze the needs on both sides and help the matchmaking. The scenario enables us to identify what are the needs of the public bodies and how SMEs have to adapt (in terms of regulations and services and in terms of technology) in order to work cross border and in order to interact with other SMEs. It also allows SMEs and public bodies to carry out a reality check before a real implementation. The scenario can be operationalised in three different ways depending on the entity that start the ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

collaboration.

1) A local SME willing to pilot its solution in a foreign country contacts the local living lab. The living lab starts an enquiry on what would be the best living labs where to pilot that technology and contact them. 2) A local SME that has already identified a target market and already knows a foreign living that could help in his business contact the living lab asking for opportunities to test its technology cross-border. 3) A local public body looking for a technological solution contacts the local living lab. The living lab contacts both local and cross-border SMEs in order to provide the best technological solutions. Table 2-4: Cross border living labs networking scenarios (main elements)

Homecare and independent living

Energy efficiency

eManufacturing

eParticipation

SME identifies the opportunity (eg. exploring new market) transferring the innovation Local SME contacts the local living lab Matchmaking crossborder living lab Scoping the project, in particular planning the transfer process Local ecosystems requirements analysis and alignment activities Stakeholder identification and engagement agreements, contracting Project coordination Market potential analysis Evaluation and lessons learned

SME identifies an opportunity and develops the business case SME contacts a local living lab Local living lab finds a match and identifies a living lab in a cross border environment The local living lab facilitates planning with the new living lab and the SME The new living lab collects local stakeholders and takes over The new living lab leads the project, using RDI management tools The new living lab assesses the market potential of the business case The living lab and SME evaluate the benefits and plan next steps

Opportunity identification of using a common platform for cross-border collaboration among SMEs and LLabs Searching partners and making agreements Agree on business model and IPR management Sharing the collaborative platform New forms of collaborative innovation among SMEs and LLabs emerge Acquisition of new customers

SME identifies opportunity of enhancing the service SME contacts local living lab Local living lab matchmaking with cross border partners Local living lab identifies cross border technologies that could be transferred to the local partner Agreement with foreign partners Transfer of technologies to local living lab Local living lab testing for contextualisation

Scenarios can be based on building blocks. We have used a visualization tool (Windows Office Visio) as a graphical tool to develop scenarios. This can be of use in the development stage of pilots and in the methodology development process itself (Fig. 2-2, 2-3).

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Fig. 2-2 Graphical representation of a scenario

Fig. 2-3 More detailed graphical representation of a scenario

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

3. Structure of Methodology Framework and Toolbox This chapter introduces the APOLLON methodology framework. We first look into generic and specific elements of methodology. Thereafter we formulate a set of “how to” questions which lie at the basis of the practical methods & tools portfolio. Besides we look into underlying methodology issues. Finally we summarize the methodology portfolio, which is then further elaborated in subsequent chapters.

3.1 Generic and specific elements of the methodology

The APOLLON methodology framework comprises “generic” as well as “specific” elements. Generic methodology elements are largely independent from the local contexts in which Living Labs operate, and include a set of general processes, procedures, guidelines, principles, methods and tools for setting up and operating cross-border networks of living labs to support SMEs in research, innovation and market development activities.

Besides, the APOLLON project experiments on cross border networks of living labs in specific business areas, which are characterized by specific requirements. Specific methodology elements are derived from the specific challenges found in the experiments conducted in these business areas. In each of the experiments, a collaborative network consisting of one or more SMEs and one or more living labs has been constructed, to experiment a specific collaborative research, innovation and market development activity.

3.2 “How to” questions for categorizing methods and tools

APOLLON methodology for supporting the set up and operation of cross-border living labs networks is based on a set of “how to” questions. Answers to these are relevant for different types of stakeholders. Methodology issues of primary, direct interest for business, research and policy actors involved in joint cross border RDI are the following: •

•

How to set up, plan, operate and possibly terminate or expand a cross border living lab network. Emphasis is on establishing the organizational arrangements, infrastructure, planning etc. Methods and tools helping to answer this question are relevant for those aiming to set up and conduct a living labs network for the purpose of joint RDI. How to conduct joint research, development, innovation and market creation activities in the living lab network. Here, the living labs network is in place and focus shifts towards the RDI activities in the living ab network as they are actually carried out. This issue is relevant for those directly involved in cross-border RDI as well as in managing the living labs research and innovation. How to address the context-specific cross-border networking challenges. Here we address the four identified harmonization and interoperability challenges: the challenge to develop common ecosystems, common benchmark frameworks, common platforms and common

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

integration frameworks, which constitute the cross-border living labs network. How to collaborate within the cross border living lab network and how to organize the network as a collaborative network. Collaboration is a specific “horizontal” aspect of the living labs networking. Partly it relates to collaboration in the creation and management phases and partly to the collaboration in doing RDI or market creation, mentioned above. However we consider it as useful to highlight collaboration guidelines as a specific issue (Chapter 9).

3.3 Fundamental methodology questions

Besides the set of primary questions on how to set up the network and how to carry out RDI, there is a more fundamental question: How to establish a network of cross border living labs as environments of open and collaborative innovation. This question refers to broader theory and methodology questions that are relevant from policy as well as scientific point of view. These questions also relate to the issue of methodology development as a process, in the sense of action research. •

•

How to facilitate open innovation and open business models in crossborder networks of living labs. The issues of cross-border living labs networks are examples of the general phenomenon of effectiveness and design of innovation networks. Whereas the open innovation concept has been developed in the context of single organizations within their value networks (Chesbrough, 2003, 2006) it is highly relevant in the context of establishing sustainable collaboration networks. How to apply action research approaches to innovation projects in cross border networks of living labs.

Within this second topic different aspects can be identified: •

•

How to design, plan and evaluate the experiments (or RDI projects). A high-level approach within the pilots follows the phases of 1. Preparation of experiments, 2. Set up of experiments, 3. Cross border piloting, 4. Evaluation. A common research framework based on a design science approach guides the experimenters in structuring the activities in the experiments. How to conduct joint research, development and innovation as “action research”. This issues is strongly related with the design and planning of experiments, Action research establishing collaboration between users, SMEs and researchers focusing on joint development and joint problem solving. Action research should be considered as a key methodological concept for living lab projects. This question is relevant both from the point of view of the over-all Apollon project as a scientific research project and from the point of view of Apollon as an “action research” project. How to develop and validate the methodology during the piloting. This “dual” role of pilots is a specific but important topic within the aforementioned one. The “action research” approach of Apollon implies a strong interaction between methodology development and methodology application within the experiments. This question is also relevant for future projects as methodologies need to adapt to the situational context.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

â&#x20AC;˘

How to evaluate the impact and added value of living labs networks. Impact and added value evaluation will be evaluated both during the project (as part of the action research cycles) and at the final end of the project. This is based on key indicators and measurement techniques related to these indicators as well as based on joint evaluations with all stakeholders involved. This question is relevant both from the point of view of Apollon as an innovation project which needs clear results and Apollon as a scientific research project which looks at new approaches to impact assessment.

This set of more fundamental methodology questions is relevant from the perspective of policy as well as from the perspective of Apollon as a scientific research project which generates knowledge and insights of use for next projects. The two sets of questions clearly interrelate, however should be clearly distinguished. In this sense Apollon has a dual importance: it should generate concrete results as well as knowledge and insights of wider interest. Through our approach of action research these dual purposes are aligned and create important synergies. Apollon methodology supports the setting up, running and assessing of living labs networks for joint research, development and innovation. The methodology is developed in an iteractive approach, together with the actual process of setting up and running the thematic living labs networks. The methodology is applied to the experiments and also learns from its application in experiment settings. The methodology must be transferable and prone to generalization to support conducting pilots and experiments in and by any network of living labs.

3.4 Overview of the methodology portfolio

The methodology framework developed within APOLLON distinguishes different categories of methods, tools and guidelines (Figure 3-1). We distinguish different purposes of these methods, tools and guidelines: 1. Support the creation phase (preparation, setting up, planning) of the crossborder network. The creation includes preparation and planning of the living labs network until it can be launched.

2. Support the general operation of the cross border living lab network, when this network is set in place. Methods and tools are required that will support the research, development, innovation and market creation activities within the network.

3. Resolve interoperability challenges specific for pilot contexts. Within APOLLON these challenges address the use of common elements across the cross-border network. These common elements include 1. ecosystems, 2. data benchmarks, 3. platforms, 3. service frameworks. Pilot contexts differ in terms of e.g. stakeholders, their objectives, the actual innovation. Apollon distinguishes four pilots characterized by four distinct challenges to be addressed within a pilot. 4. Resolve specific problems or issues. Besides the key challenges, many specific issues are to be addressed that require specific method, tools and solutions or practices. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5. Address overarching issues in cross border networking of living labs. Here we point to the general, “foundational” theories and methodologies that are useful to guide the strategy for creation of living labs networks for open and user driven innovation. The methods, tools and guidelines will also include collaboration guidelines, of interest for actors and organizations. Because this is a “horizontal” issue this is not reflected in one specific category but included in the categories defined above. Still, the aspect of collaboration merits specific attention.

Fig. 3-1 visualises the methodology structure. The vertical columns represent the different pilot environments whereas the horizontal rows depict the main methodology emphasis. Many methodology elements are generic and can be applied in different pilot environments. The top row of specific methods and tools depict methodology elements that have been specifically elaborated within one particular pilot. However this should not be interpreted as a black-white representation. The remainder of this report provides summary descriptions of methods, tools and guidelines addressing innovation in cross border networks of living labs and SMEs. The description follows the following structure: 1. What is the issue addressed by the method;

2. What is the solution provided by the method;

3. How relevant is this method for the APOLLON issues;

4. What is the target group addressed (e.g. SMEs, living labs): 5. Has the method been validated; 6. Sources and references.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Fig. 3-1: Overview of Methods, Tools and Guidelines

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

4. Setting Up and Planning Cross-border Living Lab Networks Methods, tools and guidelines in this category focus on the initiation and creation phase of the cross border living labs network, supporting the preparation, planning and setting up of the network. Specific methods, tools and guidelines presented here are the following: • • • • • • • • • • •

Business plan for a cross border living labs network Cross border living lab network development plan Detailed cross border living lab network planning Business opportunity identification and analysis Partner search and selection Business model design for cross border networks IP based business models for open living labs networks Consortium contract agreement for collaboration in a living labs network Profiling of living labs and SMEs for finding partners IPR handling and knowledge base Cross-Border Living Lab Partner Contracting

4.1 Introduction and overview

Setting up and operating a cross-border living labs network focuses on the dynamic development of the cross border network. Different phases of evolution can be distinguished, reflecting the life cycle of the network from setup via operation to termination. Table 4-1 defines these main phases and outputs. The activities that make up the definition can be further elaborated and described. Table 4-1: Setting up and running the living labs network; phases and outputs

D1.4 Recommended Toolset and Collaboration Guidelines

At the start of the APOLLON project, the connect phase as well as the plan and engage phase have been largely completed. For new projects or initiatives successfully completing these phases is of critical importance. The setting up of the living labs network corresponds with connect and plan-engage. Key processes are preparatory planning, consortia formation and network finalization. These processes can be further detailed as Fig. 4-1 shows. In the context of APOLLON, several activities have already been carried out at start of the project, e.g. preparatory planning and consortia formation. However for new projects these activities remain critically important.

Fig 4-1. Key processes in the setup phase of connect and plan the living labs network

As already described, for each of the experiment settings, Apollon will develop a scenario description which aims to bring detail and context into the phased development. Below is the initial, general scenario which, however, needs to be adapted to the different experiment settings and also needs a more detailed elaboration. The scenario description should match the cross border living lab network activities as they are in place.

Fig 4-2: Initial scenario for SME support in a living lab network

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

A more detailed identification and elaboration of the steps and activities will enable us to identify the concrete needs regarding method & tool support.

Requirements and needs as regards methods and tools can be discovered through a scenario exercise. Experiment organizers should describe the scenario of â&#x20AC;&#x153;living lab network in actionâ&#x20AC;? that applies to their situation. This is an important step towards agreeing on methods and tools support.

The next table 4-2 provides an overview of activities and processes in the phases. Such an overview should be adapted to the situation in each of the vertical experiments. Table 4-2: Detailed processes / activities in the living lab development life cycle

It is important to identify the sequence of processes in such a way that they represent a consistent scenario of cross-border living labs network support, where tools and processes are presented in a coherent manner. Fig. 4-3 below is an attempt to create such a more specific scenario.

Fig 4-3. Detailed example of cross border networking tool support

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Looking more detailed towards methods and tools support, the following table presents some examples of concrete methods and tools to be used in the different phases. Table 4-3: Methods and tools in the living lab development phases

Previous projects such as Corelabs, C@R and ECOLEAD (for collaborative networks) have developed approaches or methodologies of relevance for the category of methods and tools discussed in this section. ECOLEAD has developed a comprehensive methodology for creating collaborative networks, addressing various issues depicted in Fig. 4-1 such as preparatory planning, consortia formation and network finalization. Corelabs has addressed setting up and configuring living labs however the proposed methodologies lack concreteness and do not address cross-border collaboration but may provide some inspiration. Table 4-4: Useful methodologies from other projects for setting up and running living labs

Method, tool, guidelines, concepts

Project

Scoping, planning and project management, setting the general direction of the living lab project

ECOSPACE

IPR management in collaborative networks

Ecolead

Methods for creating conditions for living labs as open, real-life and cooperative innovation environments (create partnerships, appropriate business models, user community, capacity for adoption and change, common agreement about goals) Partner search in collaborative networks Contracting in collaborative networks

Managed development of living labs (maturity development)

Common platform and services shared by different living labs Business models for sustainable living labs

Participative and cyclic development process ICT PSP Project Reporting

Ecospace, also C@R

Ecolead Ecolead C@R

C@R, Ecospace C@R

C@R and other projects

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

4.2 Business plan for a cross-border living lab network Issue: The initial activity for stakeholders who are potentially interested in creating a cross-border network of living labs is to make a strategic decision to invest resources. This decision can be justified on basis of a “business plan”.

Solution: This business plan states the goals, justifies why these goals are attainable, and sets out a plan to achieve them. The business plan presents an evaluation of the value creation in setting up the cross border living lab network. Benefits, costs and risks must be assessed, for individual partners including SMEs and Living Labs (the “business case”), as well as the full partnership. The business plan will also clarify the financial needs and request for funds or other resources. Different structures of such plan are possible, below we have chosen one. In relation to cross-border aspects, the particular aspects to be covered are stakeholders, risks, business concept, and partnerships needed. Business plan structure

1. Vision statement 2. Stakeholders and people 3. Description of the business project, business concept, business model, value proposition 4. Market analysis, customers, demand 5. Financial justification, funding 6. Risks assessment 7. Implementation plan (e.g. partnerships, infrastructure, market development)

Relevance: Setting up a cross border network of living labs is a strategic decision. Initial decision making should be evaluated carefully in terms of benefits (short term and longer term), costs, investments and risks.

Target group: Primary target group are Living Labs as orchestrators of the living lab network.

Validation: Developing a business plan was not evaluated or validated in APOLLON as APOLLON was started as result of accepting a project proposal in the CIP ICT-PSP. However development of a business plan has explicitly been recognized as a critical step within APOLLON e.g. within the WP2 pilot on Home Care and Assisted Living. Sources: Many public sources are available about how to develop a business plan. The concept of Open Business might be of relevance for initial living labs network decision making. See: http://en.wikipedia.org/wiki/Open_business.

4.3 Cross border living lab network development plan

Issue: Setting up the living labs collaborative network is a critical phase, covering stages of connect, plan/engage and operate. The network development plan identifies the key steps and activities from connect to operations and sustainability. The key activities are preparatory planning, consortium formation and network ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

finalization. Preparatory planning includes opportunity identification, partner selection and rough planning. Consortia formation is based on partner search and partnership agreements, network composition and network business model evaluation. The finalization stage includes detailed planning and business modeling, contracting and launching the network. Solution: A guideline is offered to support SMEs and Living Labs to plan the setting up of the cross border living lab. This guideline helps them to identify critical decisions and prepare for next steps.

Relevance: The network development plan can be considered as highly relevant as starting point for realizing the network. Target group: Living lab as orchestrator, local government agencies.

Validation: The rough network development plan (phases and underlying activities) has been in main stages has been discussed many times within the consortium and has been accepted as a cornerstone of the methodology.

Sources: Camarinha Matos a.o. (2008) describes a comprehensive framework for creating virtual organizations. Elements of this framework can be adapted to the problem of cross border living labs network creation.

4.4 Detailed cross border living lab network planning

Issue: The detailed planning becomes important once the partners have been selected and collaboration agreements reached. It includes the development of a detailed cross border living labs network plan and its governance principles.

Solution: The detailed cross border network planning includes following aspects:

• • • •

•

Defining the collaboration processes and the business processes of the cross border living labs network. Elaborating the governance structures.

Planning the infrastructure needed to enable the cross border living labs network, planning to cope with cross border differences.

Planning how to cope with regulatory differences, differences in value networks and ecosystems Marketing plan, customer relations development plan.

Target group: Living lab as orchestrator,

Validation: The detailed cross border network planning has not been explicitly elaborated for Apollon as this project was already starting. However, the pilots have developed their own work plans. Several issues appeared that show a need for more careful business splanning in the early stages of the project.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

4.5 Business opportunity identification and analysis Issue: Starting point of the formation of cross border networks of living labs is the international business opportunity for SME innovation and market creation, as identified by the SME, or with the living lab, or through contacts with Innovation Centers and comparable entities. The identification of business opportunities can be supported in several ways. The SME might have already some idea of how a technology they own could be exploited internationally, which needs concrete elaboration and advice. In many countries Innovation Centers or more specialized organizations are active and are in a position to provide advice and support to SMEs to help assessing the capabilities and readiness of SMEs for internationalization. The Enterprise Europe Network is also an important network, which is also engaged in matchmaking activities. Solution: A checklist for SMEs is proposed to support them in elaborating the business opportunity associated with a new technology they own, and to assess their capabilities for exploiting the technology internationally. The checklist addresses the transfer of a technology opportunity to another country. It also addresses the capabilities of SMEs to act internationally. As Innovation Centres are also active in supporting SMEs, the Knowledge Centre portal should contain a list of Innovation Centers and comparable intermediaries across Europe. Existing checklists should be made available and existing good practices for SME internationalization as well. Important aspects of a checklist are: Political factors; economic factors; Social factors; Technological developments; Legal issues; International; Environmental; Demographical.

Relevance: The checklist and networks offered in this tool address the cross-border transfer of technology solutions in order to create new markets. Existing intermediary organizations such as Innovation Centers already are active in providing tailored advice to SMEs. Living labs should link up with these existing intermediaries which offer complementary services. Target group: SME involved in internationalisation, Living Lab supporting the SME

Validation: The checklist has not been developed as such however the Homecare and Independent Living pilot provides several elements that can be part of it.

Sources: DG Enterprise, Supporting the Internationalisation of SMEs. Good practice selection (2008): http://ec.europa.eu/enterprise/policies/sme/documents/internationalisation/. Link to innovation centers: http://www.enterprise-europenetwork.ec.europa.eu/about/branches/eg/cairo-giza/technology-innovationcenters

Relevant activities can be found also in the context of Venture Labs and Business Incubators.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

4.6 SME partner search and selection Issue: SMEs who aim to transfer their technology to a cross border market may want to engage in collaboration with local partners, for collaborative product or service development, to collaboratively introduce products and services, or to jointly do research. They also might want to contact a living lab to find partners or to explore product / service modifications and testing. Solution: A template has been developed which supports SMEs in specifying their needs for partners, technologies and advice.

Relevance: Within APOLLON a clear need has been identified from the side of SMEs to build contacts and find partners internationally. These needs cannot be fulfilled by living labs as this is not their core competence. Living labs should build relations with specialized intermediary organizations. Target group: SME involved in internationalization, Living Lab as supporting the SME Validation: The template has not been validated.

Sources: Partner search and matching services are offered by Innovation centers and by the Enterprise Europe Network, co-funded by the CIP programme. http://www.enterprise-europe-network.ec.europa.eu/index_en.htm.

Enterprise Europe Network services: ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • • • •

Going international: business database with thousands of profiles; matchmaking events

Technology transfer: database of technology offers and requests, organised by sector, 13.000 profiles. Matchmaking facilities. Access to finance: support to acquire venture capital and loans, tax credits

Research funding: support to explore the opportunities of EU projects; assess technologies, support to develop project plans

Advice on EU law and standards: impact of laws and regulations on business

Intellectual property and patents: advice on how to protect ideas and technologies, contacts with lawyers

Another network which is of interest is the Technology Innovation Network (TII), which is a network of European technology transfer specialists and innovation support providers (www.tii.org). This network has 230 members in 40 countries. Partners are technology institutes, science parks, incubation centers, consultants, public and private innovation centers. Some of the members are: Syntens (Netherlands, www.syntens.nl); Connect Midlands (UK, www.connectmidlands.org); European Business and Innovation Network (Belgium, www.ebn.be); Central Transdanubian Innovation Network (Hungary, www.kdriu.hu); Business Creation centre (Austria, www.bccs.at); Advansis Oy (Finland, www.advansis.fi). Over-all, and this is of interest for creating Domain Networks within APOLLON, a wide spectrum of SME support organizations is active across Europe, providing general service such as partner finding and matchmaking as well as more advanced services such as internationalization support, and using a variety of business models.

4.7 Business model design for cross border living labs networks

Issue: A living lab network business model defines the totality of stakeholders and resources needed to implement a collaborative partnership and to jointly create value through offering living labs services to target groups. It determines the business modalities, working relationships, the added value per stakeholder, governance and legal frameworks etc. A network of living labs may apply different models than single entities, in particular if they are across different countries.

Solution: Different approaches have been elaborated to business model design. The STOF template, comparable to CANVAS, offers a structured approach to establish a viable business model addressing four aspects: Service, Technology, organization and Finance. It consists of a set of questions for each aspect. For example regarding Service the questions are: Who is the customer/ Who is paying for the service? Who is the end user? How does the proposed service fit into the daily lives of the intended customers / end users? More explicit than STOF, the CANVAS model (Osterwalder) focuses on infrastructure, e.g. the activities necessary to implement the business model, the resources that are necessary to create value, and the ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

partner network in terms of alliances needed. In a cross-border setting, creating partnership agreements may need specific attention in terms of legal arrangements.

Business model building block framework (Osterwalder)

The following aspects of the business model are relevant in terms of cross border transfer of solutions (e.g. in relation to the healthcare and assisted living pilot): • • • • • • •

Value proposition in the new context, which can be different from the original context

Targeted customers in the new context, but also the stakeholders other than end customers (e.g. insurance, local government agencies) Distribution channels: marketing and distribution strategy should adapt to the local situation.

Partner network: will be different in the new situation as different partners and different roles will be involved. Revenue model, this could be different in the new situation because of the different actors and their role.

Infrastructure: different technical (network infrastructure and services) and organizational infrastructure will probably be required in the new environment.

Last but not least, adoption of the business model by the stakeholders involved, and resolving any legal and regulatory constraints hindering introduction of the solution.

Relevance: Business model design is highly relevant in the initial phases of preparing and planning the living labs collaboration network. Business model aspects are addressed in all pilots.

Target group: The Living Lab may support SMEs in preparing a business model.

Validation: As partner agreements have already been prepared in advance of starting the Apollon project, the business model approach was not tested. However the business model design is a critical step in building the living labs network for sustainability. Some of the success and failure factors of the network pilots can be related to the business model agreement. Business model aspects are addressed in all pilots. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Sources: Chesbrough (2006), Osterwalder et al. (2005), Faber and De Vos (2008). For CANVAS, see also Wikipedia: http://en.wikipedia.org/wiki/Business_Model_Canvas.

4.8 IP-based business models for open Living Labs networks

Issue: SMEs owning a technology but in need of collaboration with external partners should develop an IP strategy and IP-oriented business model. The contracts (internal as well as external) governing the relations within and outside the partnership will include IP aspects. IP rights include copyright, database protection, patent protection, trademark and design protection and protection of confidential information. In an open innovation environment IP business models will reflect open collaboration. An IP business model Chesbrough (2006) distinguishes different types of business models. His “Type 5” business model targets a company that integrates its innovation process with its business model, where IP is managed as a financial asset. “Type 6” proposes a business model which is able to change and is changed by the market. Here, IP is managed as a strategic asset helping the company enter new businesses and create value (not only capture it). Companies may decide to publish or give away a portion of their IP, to create standards or to establish an intellectual commons that fosters advances that benefit the company.

Solution: A guideline for IP handling for cross border living labs is developed (TBD). The Cross-border living lab network is an open, collaborative network. Precise design and implementation of IP strategy is dependent on the particular context (pilot). There are no clear practical approaches to IP arrangements in such contexts available. Some initial guidelines can be proposed. 1. Assessment whether the assets are new. For this assessment, patent search and technology evaluations are useful. Sometimes Innovation Centers will support SMEs. 2. Assess risk level for innovative assets. 3. Creating value with IP. The sale, purchase, licensing of IP can generate value but the opportunities need to be made aware of. Different possibilities exist to explore the value of IP use. Using an IP database or IP exchanges are tools to understand the value of SMEs IP. IP handling should be covered in contacts. 4. Prepare IP strategy. Relevance: Highly relevant for SMEs participating in the cross border network. Target group: SMEs, Living Lab which is supporting the SME Validation: No validation has taken place within APOLLON.

Sources: Vraalsen and Mahler (2005), Branscombe (2001), Chesbrough (2006), Camarinha Matos a.o. (2008). Previous projects: ECOLEAD has developed methods and tools for creating and managing CNO’s, including approaches for IPR protection. Within ECOLEAD, Gusmeroli, Ratti and Serina (2007) have developed a solution for knowledge IPR within collaborative networks, based on automatic tracking, managing access rights and protection. Innovation Centers such as Syntens (Netherlands) and also in Flanders (Belgium) provide advice to SMEs on how to

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

handle IP issues. Internet: http://www.thinkipstrategy.com/ipthinktank/376/intellectual-propertybusiness-models/

4.9 Consortium contract agreement for collaboration in a living labs network

Issue: During the process of setting up the cross border living lab (in its finalization stage), different types of agreements among stakeholders (living labs, SMEs, other entities) are being elaborated. These agreements regulate cooperation among parties, and address different aspects that may need implementation through formal contracts: the general partnership collaboration agreement, and arrangement of legal issues such as IP arrangements (in relation to using technology know-how and software licensing). Both the contract structure as the process of development of contracts, and the negotiation, needs attention. The contract defines duties, rights and obligations of the parties, remedy clauses as well as other clauses that are important to characterize the goals of the contract. Solution: A guideline can be developed which considers, for networks of living labs and SMEs, the contract contents and the process for developing and negotiating the contract. A worst case “scenario” reveals the elements that need to be agreed upon. Some of the elements are: • •

• •

Identification of partner interests in relation to the cross-border project goals.

Identification of all negotiation issues, for example in relation to: access to and use of assets and resources from partners, financial or other risks of the project, distribution of benefits and costs.

Duties, obligations, rights and responsibilities of the partners. Responsibility for the cross border network. Partnership aspects, also handling of new partners and third parties.

Relevance: Contract agreements are required before collaboration in a cross border living labs network can start.

Target group: All partners involved in the Living Lab collaboration. The Living Lab could act as the orchestrator.

Validation: No validation has taken place as APOLLON pilots have started based on the project plan. Within APOLLON we have developed a more detailed contracting agreement between an SME and a living ab. Also an example living lab contracting framework from SAP is available. Sources: Past projects: ALIVE (2002) has developed contract templates for working in collaborative networks. ECOLEAD (D23.2, 2006) has developed a wizard for such contract negotiation. See also: Camarinha-Matos a.o. (2005, 2008).

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

4.10 Profiling of Living Labs and SMEs for finding partners Issue: Both SMEs and living Labs may need to find partners internationally. An SME may need to identify a living lab that is capable to support them in exploring the international market. A living lab may need to identify another living lab to establish a cross-border collaboration for that purpose. Solution: The knowledge Center hosted by ENOLL contains a searchable database with contact information and detailed descriptions of Living Labs in its Network. The information is both searchable and relevant for the process of partner finding moments in the process. Presence in the Knowledge Center makes the Living Lab easier to be found and gives it a potential source for new project proposals. In the process of partner finding for new network setup one of the main constraints is the fast retrieval of relevant information about potential partners. When a Living Lab or SME looks for a partner with particular abilities the search function will provide help. For living labs the presence in the Knowledge Center helps them in profiling to an international audience and can be used to demonstrate their participation in ENOLL. Relevance: The profiling facility is relevant in the process of searching and finding partners. Several other organizations e.g. Enterprise Europe Network also offer profiling and partner search facilities. Target group: SMEs and Living Labs

Validation: No validation was undertaken in the APOLLON pilots, as the pilots were already starting at the beginning of the project. Sources: http://knowledgecentre.openlivinglabs.eu/

4.11 IPR handling and knowledge base

Issue: SMEs may need to address the issue of how to handle IPR in collaborative projects in networks of living labs and SMEs. Intellectual property rights are important for many projects and can hinder collaboration if issues arise and are not resolved. There is confusion on what is actually is considered intellectual property and how to deal with it.

Solution: The checklist in development supports the planning phase of the establishment of the network. The checklist includes a list of the most important issues concerning Intellectual Property Rights (IPR) to be taken into account at the start of a project. These include: 1. Patents, 2. Copyright, 3. Trademarks. The checklist does not provide any actual guarantees for resolution; its only aim is to create awareness for the issues raised by IPR and for the potential problems that have to be avoided. A Knowledge Base may consist of practices on how to resolve IPR issues and may include proceedings of a workshop on Intellectual property rights that can be organized by Apollon and Enoll. Both the Knowledge base and the checklist can be made available on the Knowledge Center. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Relevance: IPR issues can seriously hinder collaboration if issues arise and are not resolved. Target group: SMEs, Living Labs as supporting SMEs

Validation: Not validated.

Sources: E.g. Vallat (2009).

4.12 Cross Border Living Lab Partner Contracting Issue: Cross border living lab network partners engage in a longer term collaboration. A contract agreement is a document where the project partners formally agree on and commit to carrying out the cross border living lab project. The contract agreement is a legally binding document.

Solution: This tool (Annex 2, Section 1) provides a template for a contract agreement between the cross border living lab partners. Every project requires formal contract agreements to be made between the partners, verified by the signatures of each party. These contract agreements should be one-on-one, that is, agreed on and signed between two partners. Therefore, multiple contract agreements should be made within one single cross border living lab project. In addition, an overall consortium agreement can also be made, nevertheless, this should not replace the one-on-one agreements as changes, surprises, deviations from plans occur in every project, and an overall consortium agreement often is too general to cover many of such situations. Producing the contract agreements should be on the responsibility of the project manager of the cross border living lab project. As the contract agreement requires elements from the project plan, it is suggested to be made after producing the project plan, however, as early as possible during the Plan and Engage phase of the cross border living lab project. Relevance: Highly relevant for Living lab network organizers and stakeholders.

Target group: Living Lab network stakeholders, Living Labs as orchestrators

Validation: The partner contracting template has not been validated as such, however the need for contracting arrangements has emerged in particular in the Homecare and eParticipation pilots. Source: See Annex, section 1.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5. Operation of Cross-Border Living Labs Networks This chapter addresses methods, tools and guidelines to support the general operation of the cross border living lab network. Methods and tools are required that will support the research, development, innovation and market creation activities within the living labs network. These will be relevant for both SMEs and Living Labs. We cover the following: • • • • • • •

General framework for conducting RDI in cross border settings Management of a network of cross border living labs Project plan development for a cross-border living lab network Planning of innovation projects within a cross border living lab network Project management tools and guidelines Collaboration tools in cross border living labs networks Performance analysis of a living labs network using KPIs

5.1 Introduction

At this point the living labs network organisational setting and infrastructure is in place and focus shifts towards the RDI activities in the cross border living lab network as they are actually carried out. Methods and tools supporting cross-border RDI are relevant for those directly involved in cross-border research, development and innovation as well as in managing the living labs research and innovation. A living lab is a continuous activity of RDI processes in a learning setting, such as idea generation, product and service development, testing, evaluation and joint learning. As these activities shift over time during projects, the living lab network will also go through a life cycle with different focus.

First we should identify the RDI activity to be supported. Joint RDI in a cross border living labs includes a wide set of different RDI activities. We may draw from the experiment environments and the scenarios to identify specific and typical collaborative situations of RDI which are challenging from point of view of cross border settings. Examples of such collaborative RDI situations include: •

• • •

Testing of a comparable product or service in a cross border setting, on different locations, and using behavioural information from these tests to enhance the product / service (example: WP3 energy efficiency). Testing and modifying a product which is transferred from one context to another, in a living lab operating in a different market (example: WP2 Homecare) Using a common platform for collaboration between SMEs and living labs (example: WP4 eManufacturing) Testing a product / service in multiple settings or locations (example: WP5 eParticipation).

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Methods and tools to support cross-border living labs networking and collaboration for RDI in such situations may include the following: • • • • •

Collaboration platforms to facilitate joint design, development and testing, as well as communication and cooperation support, in distributed environments. Web platforms that enable to access and share common services and applications. User engagement and involvement methods, that enable the involvement and support of a diverse set user groups across different countries. Methods and tools for product / service development (covering stages of idea development towards concept definition, prototyping, testing and market launch). Tools that enable to collect, analyze and store qualitative user-generated data in various contextual settings in order to create a knowledge base for the purpose of conducting human-centric RDI work.

The latter category may include platforms and tools for: Collecting and storing data; Managing user communities and projects involving target user groups; Planning, managing, reporting projects and project data, as well as project findings; Maintaining and updating target group user databases; Maintaining and managing testing facilities; User community joint discussions and feedback. While this category of tools have not been used within APOLLON, they should be part of a comprehensive method and tool collection for living labs networking support.

Previous projects have developed or brought together living labs toolboxes. As far as relevant they can be adapted to the needs in the cross-border experiment environments. Some of the mentioned concepts, methods, tools or guidelines are presented in Table 5-1. Table 5-1 Useful methodologies from other projects for conducting joint RDI Method, tool, guidelines, concepts

Project

Collaboration platforms to facilitate joint research, development, testing

Ecospace

Tools for finding opportunities

Nordic

Tools to design prototypes e.g. mock-ups, persona methods, rapid prototyping

Nordic

EAR (Experience and Application Research), including experimentation scoping, lab experiments, idea workshops, field experiments, field demonstrations, longitudinal pilots, user experience and evaluation techniques Tools for generating concepts and ideas, e.g. experience prototyping, future workshops, interactive scenarios User involvement methods, user interaction management

Action research innovation methodology: structuring the innovation process enabling joint innovation and problem solving Participative and cyclic / spiral development process approaches

ICT PSP Project Reporting

Ecospace Nordic Various C@R C@R

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The C@R living lab methodology is based on a set of methods and tools for different living lab phases and on a cyclic and iterative development approach, which brings it in line with socio-technical engineering approaches while adding the user centric perspective of user driven innovation. ECOSPACE living lab methodology is based on Experience and Application Research (EAR) which was proposed by ISTAG. The methodology is based on a living lab project framework and distinguishes different living lab activity types and support mechanisms (Box 5-1). Box 5-1: Living lab innovation methods/tools developed and applied by ECOSPACE • • • • • • • • • • •

User analysis of current work processes and technologies, quick scan Technology demonstration and experiencing workshops User scenario development workshop Experimentation scoping and planning Lab experimentation Field experimentation and pilots assessment Longitudinal pilots Building absorptive capacity Idea generation Evaluation techniques e.g. data logging, critical incidents reporting Theory building and testing

ECOSPACE elaborated a structuring of living lab innovation projects, which includes “process building blocks” characterized as follows in Fig. 5-1, together with the explanation below taken from [Löh et al. 2009]. Scoping, planning and proj ect management

Preparation and initial idea generation

“Technical” innov ation (concepts, products, serv ices) dev elopment Iterativ e ev aluation and extension

Business dev elopment

Fig. 5-1: Living Lab Engagement structure [Löh, Schaffers, Kristensen, Budweg 2009]

Scoping, planning and project management sets the general direction of the project and plans out specific steps with the corresponding content and methodologies. It thus cannot be an administratively oriented project management, but more project management driven by good understanding of concepts and possibilities, the business domain, and facilitating and motivating the stakeholders ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

involved. As such it is the key service component of the living lab as service provider.

Preparation and initial idea development has two main objectives: building mutual understanding between the stakeholders about their respective domains (absorptive capacity for mutual engagement) and eliciting ideas and requirements that feed into the initial version of the innovation.

Iterative evaluation and extension brings the respective state of the innovation into a “Living Lab” setting for different types of usage, be it controlled experiments, or open, community-type applications. The goal is to understand and evaluate the impact of the innovation, which can be also used as basis for exploitation, and to create new ideas and requirements for extending the innovation. Depending on the maturity, a new iteration can follow, e.g. changing also scope or methodology of evaluation.

The innovation’s “technical” developments include conceptualization, architecting, and implementations of new concepts, be they products or services. They are not directly part of the living lab, but need to be in close and iterative interaction. The communication flow and understanding at the interface between Living Lab project and development is essential for innovation success. The initial ideas from users should be an essential input to this set of activities, which in turn provide the elements to be evaluated and improved and extended based on new ideas. The technology development has often already started before the living lab project, but not necessarily so if the users are triggering and pushing innovative ideas. Spilling over from the Living Lab project, the innovation’s business development uses results from the collaborative project as references cases, to better understand target customer groups and build the value delivery system. However, this process is generally performed outside the opened Living Lab setting for business confidentiality reasons. Apart from project structuring, ECOSPACE has developed a useful categorization of living lab activities and their methodologies. Typical Living Lab activities or methods and tools include Business Analysis (including business model analysis); Technology Demonstration and Experience, Scenario Development; Experimentation Scoping and Planning; Idea Generation Workshop, Lab Experiment, Field Experiment, Field Demonstration; Longitudinal Pilots; Living Lab Experiment Assessment. A challenge, addressed in section 5.2, is how to make this approach useful for cross-border living lab settings.

5.2 Research methods toolbox for cross border living labs

Issue: The Living Labs community has addressed most attention to supporting RDI in single Living Lab settings. The “single living lab” methods can be used, when adapted, in cross border settings of multiple living labs. For cross border networks of living labs aspects need to be added that address the typical characteristics of distributed, cross-border settings of RDI and typical settings of the different pilots ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

APOLLON is working on, i.e. the cases of cross border technology transfer, data benchmark, business collaboration and service components integration.

Solution: A research methods toolbox framework is proposed for matching cross border living labs needs and RDI methods and tools. The framework is built on a three dimensional typology: 1. Cross border living labs challenges, 2. RDI methods and tools, 3. Outcomes and success factors.

The first step is to match 1. cross border living lab challenges and 2. RDI methods and tools. The key challenges addressed in APOLLON pilots are “technology transfer”, “common benchmarking of data”, “business collaboration” and “component integration”. For each type of challenge the key living lab activities and corresponding research methodology elements should be identified and adapted to the requirements of the challenge. Key living labs activities and elements include: • • • • • •

Business analysis of existing business environments and applications. Here we use the methodology of business modeling, e.g. following the CANVAS approach.

Technology demonstrations and experience. Scenario development.

Experimentation scoping and planning.

Experimentation and longitudinal pilots. Cross border user groups involvement.

For example “technology demonstrations” are already important in several pilots. Table 5-2: Living Labs activities and methodologies in the four environments Requirements Activities and methods Business analysis Technology demonstration Scenario development

Experimentation scoping and planning

Technology transfer

Original business environment New business environment

Common benchmarking

Common platform

Integration framework

Demonstrate technology to users in the new setting

Adapt the business scenario to the new setting

Experimentation and evaluation ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The second step is to match the 2. living labs activities methods / tools and 3. Living Labs outcomes and success factors. The living labs activities within the specific cross border settings contribute to particular success factors of living labs. This dimension also corresponds with aspects of the design research framework and action research cycle activities: • • •

Building absorptive capacity and capacity for change, to “unfreeze” for joint learning and change. Co-creation and joint evaluation and learning

Theory building and testing, aiming for understanding.

The living labs activities and related methods or tools can be mapped on outcomes defined for each of the four challenges. For each of the four challenges, the living labs activities can be designed to match the success and outputs of the particular setting. As an example, table 5-3 depicts the resulting matrix for the Homecare and Independent living pilot, which focuses on technology transfer.

Table 5-3: Living Labs activities and Methods related to Outcomes Outcomes Activities and Methods

Building capacity for change

Technology demonstration

Trust building in new setting Becoming aware of technology opportunities

Business analysis

Scenario development

Experimentation scoping and planning

Awareness of new business setting Trust building in new setting

Co-creation. evaluation and joint learning

Theory building and testing (understanding)

Involvement of new setting in new ideas development

Experimentation and evaluation

Relevance: A set of methods and tools dedicated to experimentation and evaluation focusing on specific cross-border settings is key to APOLLON. Target group: Living Labs and Researchers.

Validation: As such the methods and tools presented hare have not been validated.

Sources: Projects such as CoreLabs (2006), Ecospace (2010), C@R (2010) have developed methodology elements for “single living lab” settings. Cross-border living ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

lab methodologies as such do not exist. Some cross-border aspects are addressed by C@R which has experimented common methodologies, platforms, services and tools for use in a multi-living lab constellation (Schaffers, García Guzmán, Navarro, Merz (Eds.), 2010). Löh et al. (2008, 2009) have developed living labs experimentation and evaluation approaches for living labs.

5.3 Management of a network of cross border living labs

Issue: Cross border living lab innovation projects require adequate management frameworks: project governance and project management procedures and management tools. Cross border projects are characterized by additional complexities e.g. working with international partners, using different project management procedures and tools. Two levels need to be distinguished. The level which is described here focuses on management of a cross border living lab network seen as a temporary “project organisation”, where the cross border living lab network set up, planning and operation is part of the “project”. The second level is where cross border innovation projects can also be developed by a sustainable cross border living labs collaboration, which generates specific innovation (piloting) projects. Solution: Managing a cross border living lab as a temporary project activity needs project governance and management tools. A project management framework for this case includes following elements: •

• • • •

Living lab network business plan, which lies at the basis of creating the project and which describes the goals, KPIs, activities, resources of the cross border living lab “project organization”? See above.

Governance framework (definition of roles, responsibilities). Of high importance is to address the cross border complexities of collaboration. Risk management procedures.

Project management procedures and tools (“project” covers the lifecycle of the living lab). A cross border living lab

Living lab network development and implementation: customer relations, innovation projects development, implementation of pilots, evaluation.

Relevance: Highly relevant for follow up cross border collaboration projects of APOLLON. Validation: Not validated, as APOLLON pilots focuses on specific innovation projects.

Sources: Literature on project governance, project management. C@R (2010) has developed a value chain model of living labs where different primary and secondary value activities are described. Ecospace (2009) has developed a useful White Paper on living labs project management. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5.4 Project plan development for cross border living lab networks Issue: A project plan should be agreed among the partners of the cross border living lab project. It defines the objectives, activities, partner roles, organizational and governance arrangements, responsibilities, liabilities, profit and cost sharing, and risk management of the project. The most common challenges that projects of any kind, regardless of the context and project type, encounter are the following: • • • • • • • •

Project goals and objectives are vaguely specified.

Project partners have divergent understanding on the project goals.

The preferences of the partners with regards to the project are divergent and many times contradictory.

The responsibilities and liabilities between the partners are vaguely specified. The management structure of the project is unclear.

Changes and unexpected events occur during the project and these are costly to take care of when the project is running.

The ways in which realized risks should be managed are vaguely defined.

It is unclear as to what happens when the project is finalized and terminated.

Table 5-4: Project plan aspects to be taken into account Challenge area

Project plan requirement

Explanation

Responsibilities, liabilities, partner scope, risk management, deviation management

Project procedure specification and harmonization

Project organization, management structure, and governance model should be defined and agreed on between the partners

Ambiguous goals, objectives, expectations, preferences

Knowledge transfer and localization Project termination

ICT PSP Project Reporting

Project target specification and harmonization

Providing common project platform Project outcome validation, integration, scaling

Project targets should be specified and harmonized between partners to ensure goal, expectation, and preferences consistency and unambiguity

Cross border living lab projects require transferring of knowledge (i.e. human capital, information, technology etc. across borders) which should be organized as well as the identification of localization needs. Validation of the project outcomes in terms of their accuracy and plausibility in cross border situations, project KPIs , integration of the project outcomes to the permanent organizations of the partners, and scaling of the project outcomes should be defined

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

For the setting of cross border living labs networks, additional problems should be addressed, such as different project plan cultures, management styles, uncertainties etc.

Solution: A project plan template has been developed (Annex 2, section 9). In this method template, the guidelines how to set up the project plan as well as the contents (i.e. structure and elements) of the plan are described. In order to make sure that these challenges are taken into account and prepared for, a project plan of the cross border living lab project is needed. In addition to this, preparing a project plan has also many other purposes. It is used to build trust between the partners and stakeholders. It is used to increase transparency between the project participants. It can be used as a back-up in conflict situations. And it is used to build common commitment and sense of togetherness between the partners. Therefore, regardless of the cross border living lab domain, the project plan should take into account the factors depicted in Table 5-4.

Relevance: Highly relevant for cross border living lab organizers and project managers.

Target group: Cross-border living lab project management team consisting of representatives of key project partners (SMEs, living labs, public organizations etc.). Validation: The project planning approach is in development based on APOLLON pilots.

5.5 Planning of innovation projects within a cross border living lab

Issue: Depending on its mission and its sustainability, a cross border living lab network may develop, plan and manage innovation projects. Due to the many uncertainties, these innovation projects need careful planning. Guidelines on how to plan such projects should address the particular context.

Solution: A detailed project plan made at the beginning of the Plan and Engage Phase is proposed as a tool for the cross-border experiment. The purpose of this is to describe in detail what will be done, by whom, when, who is responsible for what, who is the experiment leader, what is the organization of the experiment, what are the liabilities of the different parties, how are profits, costs and risks to be divided between the stakeholders, what is the expected outcome of the experiment, and how is the outcome of the project to be measured (KPIs), etc. The project plan will aid especially the Experiment Manager/Owner in anticipating and answering such emerging questions as those described above as well as in making the necessary decisions. Relevance: High relevance for cross border projects. Target group: Living Lab orchestrators Validation: Not validated.

Source: General literature sources. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5.6 Project management tools and guidelines Issue: A sustainable cross border living labs collaboration will result in specific joint projects targeting specific innovations. The project needs support from its inception until completion, which includes the planning, management and implementation of such dedicated projects. Solution: Living labs projects includes different elements. â&#x20AC;˘

â&#x20AC;˘ â&#x20AC;˘

Scoping, planning and project management. This sets the direction of the project and plans specific steps with corresponding methodologies. The project management is driven by thorough understanding of the concepts. Possibilities, business domain, and stakeholder interests. Preparation and initial ideas generation. This contributes to trust among stakeholders and building absorptive capacity.

Innovation activities, iterative development and innovation. This is the actual living lab innovation process which involves users and proceeds through cycles of concept development, prototyping, evaluation and learning.

The project plan will define the objectives and approach of specific innovation projects. Elements for cross border living lab project plans include: Project definition, goals, KPIs; Activities; Resources; Project governance (roles, responsibilities); Risks and environment. Relevance: Highly relevant. Target group: Living Labs Validation: Not validated.

Sources: As indicated in section 5.1, Ecospace (2009) has developed an EAR-based approach to living labs project management.

5.7 Collaboration tools in cross-border living labs networks

Issue: The cross border living labs network establishes collaboration among different partners: living labs, SMEs, larger companies and agencies. A collaborative workspace enables partners to share and co-author documents, exchange messages, engage in synchronous conferences. Mainstream tools are offered by IBM (Notes, SameTime, WebSphere), SAP (Netweaver, recently the cloud-based StreamWork), Microsoft (SharePoint). A rapidly growing set of tools is indicated with Web 2.0 (social networking, social media). The ECOSPACE Integrated Project (2010) has developed a comprehensive set of collaboration tools related to Web 2.0 and semantic web concepts, using the basic platform of BSCW (basic System of Collaborative Working), allowing also the integration of existing tools, to support professional communities.

Solution: Cross border living labs networks will benefit from using collaborative working environments and social networking software. Different pilot challenges may need different functionalities. A document repository (like BSCW, or the system ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

used for myBBT) will be a useful first step. The BSCW system explored in Ecospace has extended facilities for presence management, conferencing, project management and other. Relevance: Highly relevant to support network collaboration.

Target group: SMEs, Living Labs, participants in cross-border living lab projects.

Validation: Several collaboration tools have been validated in the pilots, see D1.5.

Sources: New Global (global working environments), MOSAIC (mobile and collaborative working), Ecospace (eProfessionals Collaborative Workspaces), Ecolead (collaborative networked organizations) and many other EU projects. Many literature articles are available. See also: http://en.wikipedia.org/wiki/Collaborative_software. Ecospace is one of the projects that have produced an elaborate state of the art description of collaboration tools. There are a myriad of software tools to support online collaboration. Knowledge workers have real-time conferencing tools at their disposal, as well as collaborative authoring tools, workspace functionality, messaging support, functions to coordinate the collaboration, awareness information about the people they collaborate with, facilities for persistent conversations and functionality to syndicate contributions. Figure below, which is an updated version of the figure by Oâ&#x20AC;&#x2122;Kelly & Gotta (2006), illustrates the key functionalities of communication and collaboration infrastructure.

Ecospace (2007), update from Oâ&#x20AC;&#x2122;Kelly & Gotta (2006).

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5.8 Performance analysis and evaluation of a living labs network using KPIs Issue: A specific tool for project management is the use of KPIs (Key Performance Indicators). Wikipedia definition is as follows: KPIs are commonly used by an organization to evaluate its success or the success of a particular activity in which it is engaged. Sometimes success is defined in terms of making progress toward strategic goals, but often, success is simply the repeated achievement of some level of operational goal (for example, zero defects, 10/10 customer satisfaction, etc.). Accordingly, choosing the right KPIs is reliant upon having a good understanding of what is important to the organization. 'What is important' often depends on the department measuring the performance - the KPIs useful to a Finance Team will be quite different to the KPIs assigned to the sales force, for example. Because of the need to develop a good understanding of what is important, performance indicator selection is often closely associated with the use of various techniques to assess the present state of the business, and its key activities. These assessments often lead to the identification of potential improvements; and as a consequence, performance indicators are routinely associated with 'performance improvement' initiatives. A very common method for choosing KPIs is to apply a management framework such as the Balanced scorecard.

Solution: A simple KPI framework will be useful to support the management of future cross-border living lab initiatives. Within APOLLON, a KPI-based framework has been developed to measure the impact of the APOLLON pilots. This framework should be used as an overarching framework that support the evaluation of the vertical pilots, but it must be complemented with specific questions for each vertical experiment to deal with situational aspects, such as usability of technology or other experiment specific questions. This template should be applied by the experiment leaders when assessing their experiments. As a structure for the template we have chosen to apply the components of Living Lab environment, which are: Users and partners, Management, Research, Innovation, ICT tools and infrastructure and Approach (Bergvall-Kåreborn et al, 2009). Target group: Living Labs, experiment leaders

Source: See: D1.3 APOLLON Evaluation and Impact Assessment Framework, and the document “Framework for Evaluation of Cross-Border Experiments”. Also within ECOSPACE evaluation framework has been developed.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

6. Approach to Interoperability and Networking Challenges This methodology category addresses four general interoperability or networking challenges: 1. A common ecosystem, 2. A common benchmark framework, 3. A common technology platform, 4. A common service integration framework. In demonstrating the feasibility and value added of cross border living labs networking, each pilot has a complementary focus on one challenge. Jointly with pilot development and implementation, each pilot develops a suitable methodology. Below we summarize the four methodologies with particular attention to how these methodologies address, in a generalized manner, each of the networking challenges: • • • •

Common ecosystems: facilitating transfer of technologies

Common benchmarking of data facilitating adoption of technology solutions

Common technology platform to facilitate collaboration for service innovation

Common integration framework to enable user participation in service innovation

6.1 Common ecosystems facilitating technology transfer to another market

Issue: An SME has developed a technology or system for a local market, which will be transferred, replicated and exploited in another cross border market. This requires adaptation to the new market, to facilitate adoption and to meet the new user demands and market conditions. The deployment in the new market also requires a specific ecosystem.

Solution: Apollon develops a methodology and guideline to support cross border technology transfer. The methodology focuses on the identification and definition of the required contextual elements and ecosystem that is necessary for transferring and deploying a service in new markets. Three elements are distinguished: •

One key element of the methodology focuses on analyzing the required conditions for adoption in the remote situation compared with the original market: o Requirements analysis, including technical but also organizational, regulatory and legal requirements;

o Research setup to investigate user experience in the local and remote living lab, involving test user selection, in-depth profiling, data gathering, iterations and evaluation; •

o Analysis of the “ecosystem” within which a technology or system is adopted (actors, roles, responsibilities etc).

A second element of methodology addressing the technology transfer focus is the setup of a common living lab approach enabling the technology to be transferred from one living lab environment to another new living lab environment. Key elements of this approach are:

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

o Ecosystems analysis of both living lab environments. This includes agents or stakeholders, institutions, regulations and other topics. Comparison of ecosystem provides essential information for shaping the actual transfer process.

o Planning the deployment activities, such as functional testing and validation, localisation (translation of the user interface), training, technical validation, participant selection, field trials, final deployment.

o Conducting user research, focusing on differences between the local and the remote living lab and gaining insight in the remote market and in cultural differences.

â&#x20AC;˘

o Organisation of the transfer process, including defining key roles and responsibilities. An example is to appoint the transferring living lab as supervisor.

A third element of the methodology is based on the setting up of local experiments, provides a detailed methodology for setting up these experiments, and defines the transfer strategy and protocol (not yet finished).

Relevance: Planning and managing technology transfer is among the key methodologies for Apollon.

Validation: The methodology is developed, implemented and evaluated in one of the vertical pilots of Apollon (Homecare). Source: Apollon deliverable D2.1 Requirements, D2.3 Common Living Lab approach, D2.4. The methodology findings of the pilot will be generalized.

6.2 Common benchmarking of research for facilitating technology adoption Issue: Different living lab pilots for testing and validating one and the same innovative technology or system will generate user behavior information that can be combined and analysed to support generalized development and adoption strategies as well as approaches to behavioral change. Thus there is a need for a common benchmarking framework for activities within different living labs working on comparable technological innovations. The benchmark framework aims to include a service model for clients, business model for sustainability, as well as a reference model to share data, knowledge, experience and competencies and seek solutions towards more efficient resource usage. The framework aims to facilitate the scalability of technology innovations and development of adoption strategies towards the European marketplace. Solution: The methodology framework supports the setting up, conduction and evaluation of cross border pilots, where different living labs participate and exchange. The pilot actually consists of a group of very different cross border activities and local experiments. The cases in the cross border pilot have the purpose to test and evaluate new technology and change of behavior. The cases also

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

strive to share experiences, methods and tools among the living labs. The cases take the form of workshops, showcases, real-life tests and focus on different aspects, but together they contribute to the creation of the common benchmarking framework. The pilot activities - workshops, cases, testing - lead to transfer and shared use of methods, knowledge, information and solutions. The activities involved in the pilot have the main focus of cross border transfer of technology and knowledge. Different types of cross border activities are distinguished: business matching and partnerships, technology testing, and knowledge transfer. A common approach or framework for cross border pilot activities (experiments) has been developed, including research, data gathering and analysis activities. The common approach is based on several elements 1) a description of the cross border activity, including aspects such as partners involved, time frame, purpose, activity, technology involved, cross border dimension etc; 2) a harmonized research framework for any of the activities; 3) the basic scenario (flow of engagement). For each cross border activity, a similar process is implemented, consisting of a deployment plan, research, data collection and analysis. Relevance: Key methodology for Apollon.

Validation: The methodology is developed, implemented and evaluated in one of the vertical pilots of Apollon (energy efficiency).

Source: Apollon deliverable D3.1 requirements, D3.2 Use case analysis and common living lab approach, D3.3 Experiment design transfer technology and protocol.

6.3 Common technology platform for collaboration in service innovation

Issue: The challenge addressed here is how to make available a common platform which enables cross border collaboration of living labs and SMEs for product and service development. The platform will be capable of integrating real-world objects and resources (devices, business systems, humans, and processes) under the same roof. SMEs are facilitated to use and experiment each otherâ&#x20AC;&#x2122;s services. This way, new ways of collaboration with living labs and SMEs is foreseen. Solution: The methodology is based on the availability of, and access to, a common technology platform (Real World Integration Platform) developed by SAP, which connects backend business systems to the devices, systems and users in the physical world. It provides device management and integration, offers a service development and composition framework, and is capable to address a large variety of use cases. The platform through which new services can be developed and evaluated, acts as a collaboration platform helping living labs to set up cross border activities. Thus, the cross-border network of living Labs for e-Manufacturing is based on a collaboration environment depicted below. Each of the living labs involved hosts a number of SMEs. The country-specific SMEs provide and consume services through an integration and service platform. Thus intra-regional interaction and showcasing of services among the local SMEs will be facilitated. The network of living labs uses ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

the common platform in order to promote the inter-regional collaboration among the living labs. For example, an SME hosted within a Living Lab in Portugal could provide a service through the Service Platform and this service could then be consumed by another SME hosted within a Living Lab in Germany.

Collaborative environment for eManufacturing

The methodology comprises different aspects of how the platform actually is used to facilitate cross border collaboration. To that belong mechanisms for providing access, IPR, and licensing of software as well as dissemination and training.

Additionally, the methodology includes preparing a living lab environment for experimentation and evaluation in which different modifications of the platform and facilities for service development and composition are introduced and tested. Relevance: Of key relevance to Apollon.

Validation: Validated in the eManufacturing pilot.

Source: Apollon SME scenario for Manufacturing, and deliverables D4.1, D4.2, D4.3

6.4 Common integration framework enabling user participation

Issue: The challenge that is addressed here is how applications and services that have been developed for a specific local context, within a local living lab, can be adapted, reused and integrated into another application in another living lab.

Solution: An integration methodology is in development, which includes a simplified aggregation framework for integrating technologies as well as organizational, legal and other arrangements to enable the integration. The framework includes an assessment guideline of interoperability aspects. The current framework is not built upon an integration platform but focuses on approaches for using different technologies / services, developed in different contexts, in a new application context. Thus the framework focuses on adaptation to the local context, from technology point of view as well as and acceptance, property rights, user involvement, legal issues. Essential elements of the methodology are: ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

• • • • •

An simplified aggregation approach inspired by the Wizard of Oz paradigm, for combining technologies to respond to local user needs, which is based on “simulated aggregation”: a simulated aggregation of technologies is created that will be experienced as real integration by the users. Thus, users evaluate the integration of different technologies. The aggregation of applications developed in different cross border living labs is piloted and it is evaluated how integrated eMedia technologies can encourage eParticipation. Ensuring technologies interoperability for content sharing is based on SOA (service oriented architecture) principles using web services. Identifying attractive areas for eParticipation, in particular with respect to attractive innovations from user participation point of view.

Identification, selection and actual involvement and support of target users

Provision of tools and means for user participation, in particular social media and personalized cross media approaches. Approaches to overcome cultural barriers and establish cross-cultural communication, and resolve potential legal issues.

Relevance: Key methodology for eParticipation pilots.

Validation: The method is validated within the eParticipation pilot.

Source: Apollon D5.2 provides an analysis of essential criteria for implementing a successful eParticipation pilot. D5.3 presents scenarios and technical and other requirements. D5.4: Re-adjusted pilot techniques and methodology.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

7. Methods, Tools and Guidelines for Specific Cross-Border Issues The methods, tools, guidelines and practices presented in this section aim to resolve specific problems or issues that do not fall into the above categories. These problems or issues vary from very specific and limited, to general and of wider importance. The methods or tools mostly have been developed within the specific vertical pilot but might be wider applicable. They have been somewhat reformulated to address this wider application. The methods and tools covered are: • • • • • • • • • • • • • •

User interface translation Value network analysis User data benchmarking model Investigating user behavior transformation Test storylines for user communication Knowledge transfer across pilots Policy and regulations database Remote guided living labs tour by using webcam Trading platform for DMI agents Software license agreement Living lab contracting frameworks Community reporting tool Data protection template Sub-license agreement

7.1 User interface translation

Issue: For user interfaces produced as part of a product, whether they are websites or other interfaces, the language can often not be word for word translated. The context of the words and sentences as well as the ambiguity inherent to language makes this difficult.

Solution: Pictures or screenshots are made of the original user interface at every possible state of the device or system. Every state includes the all possible reports and situations that the device or web service can give. These screenshots or pictures are copied into the slides of a PowerPoint presentation. Also other software used to make presentations can be used. In the notes section under every slide the context and use of any picture is explained, if needed.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The translator places textboxes over every piece of text in the pictures, making it look like it works in the language needed, and puts any comments to particular slides in the notes section of that slide. The presentation is then returned to the producer of the product/service who now knows how to translate the texts and can update the system. In this way the context of the words is visible and the functionality can be preserved better. Development: Within the Homecare pilot. Of wider relevance.

7.2 Value network analysis

Issue: Introducing and adopting a technology or service in another environment or market requires a thorough understanding and possibly the modification of the local value network or ecosystem. It should be determined what kind of value network or ecosystem, and associated roles, responsibilities, rules and collaboration processes must be in place in order to successfully conduct cross border pilots. The concept of ”value network” or “web of relations” builds upon the network of actors (people or organizations) and their roles, within the context of a common “business model” for generating value, which can be tangible or intangible. The “business ecosystem” perspective is wider and addresses the sustainable community of interacting organizations and persons, within which we find forms of cooperation as well as competition. For our purpose we use the term value network only. Solution: Analysis of the value network around a socio-technical solution aims to prepare the transfer of the solution to a new environment. There is a need for recommendations on how to “replicate” the value network or at least how to replicate essential elements into the existing value network. The approach is based on interviews and studies and consists of the following elements: •

Value network actors identification. Stakeholders within the network include: end users, Living Lab, Technology providers, Communication service provider, Knowledge partners, System integrators, Local authorities, Civic associations, providers of non-profit or commercial services, regulation agencies etc. The interactions (resource flows, decisions, and outputs) between the actors should be identified to visualize the value network, both for existing and receiving environment.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

Roles and responsibilities matching. Actors in the original value network fulfill roles and responsibilities and pursue interests that should be matched in the receiving value network. The current match should be assessed.

Gaps and conflicts identification. Missing roles, obligations, functions as well as conflicting roles should be identified. For example in the domain of regulations, policies and legal requirements, missing roles can be overlooked easily: privacy laws, patient rights, insurance regulations, healthcare laws, municipality regulations etc.

Identification of options to resolve gaps and conflicts. This is the work of actively changing aspects of the receiving value network to accommodate the adoption of the socio-technical innovation. The work may include negotiations with actors in order to reach agreements concerning roles and responsibilities of actors. Design the business model for the new value network. Eventually, value network analysis should lead to creating a modified business model governing the relations concerning the adoption and use of the socio-technical innovation within the receiving value network.

The work in Apollon has realized several aspects of this methodology. The living labs serve as providers of essential information. They also are responsible for modifying the value network and proposing new business model elements.

Development: The approach is developed within the Homecare pilot. Aspects of value networks and ecosystems are also relevant for all other pilots in particular ePartipation and Energy Efficiency.

7.3 User data benchmarking model for technology testing

Issue: In order to compare and use results in different living labs, of different cross border experiments on how technology influences user behavior, an interpretation model for benchmarking of different user data sets is needed.

Solution: A “User data benchmarking model” is a data framework which relates pilot design characteristics and user behavior outcome data. Pilot design characteristics are defined and described, such as pilot objective, environment characteristics, actors involved, technology specification, and user group characteristics. Pilot outcomes are the different user behavior and feedback data associated with the pilot, as well as the technology modifications undertaken on basis of user feedback, and lessons learned from the experiment. Application of the benchmark model and using the resulting dataset is relevant for SME advanced technology developers as well as for pilot organizers. Within a cross border setting, the different experiment organizers will benefit from the knowledge, data and evaluations made available, in order to optimize their experiment design. Development: The approach is in development within the energy efficiency pilot (smart metering). ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

7.4 Knowledge transfer across cross border living labs Issue: A method is needed to facilitate information exchange and knowledge transfer regarding testing and evaluating of solutions experimented in different cross border experiments on the same topic. In this case introduction of smart metering technology and user behavioral change.

Solution: Different are used, such as real life tests, showcases, workshops and roadshows in order to facilitate knowledge transfer in a cross border network of living labs. Development: The method is developed within the energy efficiency pilot.

7.5 Investigating user behavior transformation

Issue: In many living labs environments there is a need for a method to study use transformation. The proposed method is targeted at stimulating use of new technology, which in turn influences user’s behavior. The aim of this method is to provide Living Lab managers with a method framework that facilitates the design of user involvement studies. The aim of this method is to support and stimulate users to change their energy-consumption behavior by stimulating them to use the implemented innovation. The underlying proposition is that users that are guided and encouraged to use innovations are stimulated in their innovation decision processes which in turn leads to changes in their social systems where behavior is one part. This framework should be envisioned as both a framework to guide the process, but also as a template for documenting the case. This is important since the aim of the energy efficiency case is to share knowledge and then develop a methodology to study behavior change based on the collected experiences. Solution: The method is partly directed to setting up the user behavior experiment, partly to the process design. The set up of the experiment includes the targeting of user groups and the roles of partners during the pilot and test. The process design includes a number of elements: • • • • • • • • • •

Technology demonstration and training us technology usage. Functional testing (in cross-border setting).

Translation of user interface.

Selection of user interaction tools, e.g. social media. Set up collaboration agreements among partners.

Develop tools for comparing results from implementing the technology. User input gathering, tools. User interaction scheme. Field testing.

User interaction based on a test storyline.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

Evaluation and documentation.

Development: The approach is developed in the energy efficiency pilot. The method is strongly related to the user data benchmarking model.

7.6 Development of test storylines for user communication

Issue: The problem this storyline method aims to contribute to is the problem of designing tests in similar manners across borders. By means of this storyline, knowledge on methods, questions and approaches can be shared among the project partners. This template is also aimed at supporting the communication between the Living Lab and its users to make sure that they understand what is required from them during the test they plan to enter. The intended usage of the guidelines is to support the design of the user testing within the energy efficiency pilot. Solution: This is a template to guide the process of designing the test for a longer period of time. The approach covers the following topics: • •

•

• • •

Test duration.

Test assignment.

Technology description. The technology description contains a test storyline regarding the technology, which is a tool for test designers to ensure that all functionalities of the technology are covered and where it is ensured that the user tasks are meaningful and related to the functionalities to be tested.

Test description.

Description of technology functionalities. Test evaluation.

Development: The approach is developed within the energy efficiency pilot. The method is strongly related to the user data benchmarking model and to the method to study user behavior transformation.

7.7 Policies and regulations database

Issue: Living Labs and SMEs willing to work together in a network may need to

understand the regulations and policies concerning how to set-up contracts with local partners, import of hardware equipment, tax regulations, legal aspects concerning cross-border collaborations. There is a need to provide answers to questions like: •

• •

How to do business in such a country? Are there any pre-requisites before being able to start doing business in this country, e.g. have a registered local contact/representative?

Who knows about the relevant regulations to sell a technology (e.g. smart meter) into the country or would it be easier to find a local hardware provider? What to consider when licensing software to a local SME in this foreign country.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

How does “OEM”–like or software-licensing contracts look like in that country.

Solution: Living Labs and SMEs will access a database of information and experts. The approach is based on following steps: • • • •

Identification of the business (doing business indicator). Collect available information sources, prioritize Identify the need for external experts. Find and contact experts.

Development: Proposed within the eManufacturing pilot. Related approaches are offered by entities such as Innovation Centers, Chambers of Commerce, and Enterprise Europe Network. It is recommended that ENOLL works together with such existing initiatives or organizations as they should be part of Living Labs networks.

7.8 Remote guided living labs tour by using webcam technology

Issue: Customers ask for references and showcases in a real-world setup of technologies and services they are interested in. For cross border businesses it is sometimes very difficult for both business partners to either get sufficient information about the technology offered by a provider or to find out about the real requirements of a customer, as the involved companies are far away from each other. There are travels required either to visit each other or to meet at trade fairs, to get a better understanding of the needs and the potential value, which implies high costs, you are usually trying to avoid in early stage negotiations. The combination of video and audio for online demonstrations in a live and interactive mode is therefore highly of interest.

Solution: Remote guided tour through a living lab by using webcam technology. The approach requires participants to the tour to set up a webcam and tracking capabilities to follow the guide and the technology demonstrations. Video-audio conferences will support the tour. The approach also can be combined with application sharing e.g. sharing explanatory pictures or slides. Development: eManufacturing pilot. The approach is contributed by SAP.

7.9 Platform for cross border trading of services

Issue: Service providers (in particular SMEs) require a mechanism to offer and trade their services across borders in new target markets, because they usually do not have the seize and the money to invest in market research or business development nor do they have large budgets for promotion and marketing. In particular when they need to find early adopters and future customers for new product/s in a market they are not familiar with, they would need local partners who know the business environment. An Internet-based trading platform or a marketplace amongst networks of Living Labs that offers access to end users and consumers, especially demanding innovative products and services in the industry ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

they are targeting at, would help to moderate the processes of finding the right partners, users and future customers to incubate business collaboration.

Solution: Whilst the main focus of trading in the services industry is on electronic services (e.g. web services for electronic device integration, remote maintenance services) an Internet-based platform or marketplace may also cater for B2B services that require local/on-site interaction (e.g. consulting or set-up of systems). Such a trading platform or marketplace could provide support for • • • • • • • • • • •

Describing a service from a technical, functional and business oriented view (e.g. pricing, technical access specification, usage, regulatory and legal restrictions). Describing und publishing the request for a service, help, support, etc. Matchmaking between service offers and service requests.

Trading of software modules developed by independent software and service providers.

Offering and selling the software and software modules via a web channel (web shop). Deploying a service electronically into a service runtime.

Finding local partners providing relevant on-site interaction with a user/customer. Finding market-compliant local technical components.

Keeping track of the service implementation and usage.

Allowing certifying service offers incl. their service providers.

Pricing and billing of the goods and services traded via the platform.

Development: eManufacturing pilot.

7.10 Software license agreement

Issue: Within a living lab setting, a license agreement is often necessary to enable SMEs to use proprietary software of other parties. These parties may include technology providers or SMEs. Solution: A software license agreement defines the terms and conditions, including IPR and grant restrictions, as well as opportunities for modifications and add-ons, and confidentiality and data protection issues.

Development: eManufacturing pilot. An example is the SAP Development License Agreement for Research Software. Based on this example dedicated agreements can be designed tailored to the situation. Software license agreements are also be relevant in the eParticipation pilot.

7.11 Living lab Contracting Framework (1)

Issue: Living labs working together in a network, and working with SMEs, may need a contracting framework to define roles and enable the use of Living Lab services. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

These services include the provision of infrastructure, testbed services, scenario development, joint development, demonstrations and other.

Solution: The Living Lab Contract Framework consists of 3 templates to define and secure the partners role, service and contribution: • • •

Check list for living lab cooperation agreement;

Living Lab cooperation agreement, describing the rights, obligations and statement of work between the living lab and a partner;

Living Lab status description, presenting the evolvement of the living lab and explaining the contribution of living lab partners to specific living lab objectives.

Development: The Living Lab Contract Framework is proposed by SAP and services as “good practice”. It includes Living Labs Status Description, Living Lab Cooperation Agreement, and Checklist to Prepare Living Lab Cooperation Agreement.

7.12 Living Lab Contracting framework (2)

Issue: Need for a basic contract between test users and living lab.

Solution: The template contract is split up in the following parts: basic agreement, pilot specific annex and notification and authorization form for gathering personal and privacy sensitive information. This tool provides a basic contract that can be used between the Living Lab and the test user. It provides a number of elementary elements that have to be taken into account by both parties such as: • • • • •

Terms and conditions Responsibility Privacy

Liability

Confidentiality.

The basic contract is structured and drafted in such a way that it creates a general agreement between the test user and the Living Lab. In essence the test-users agree to be part of the Living Lab and engage him/herself in the participation of (various) research project. In this general agreement a number of central elements are defined in terms of conditions, expectations, responsibilities etc. for both parties. These principles apply for all projects in which the test users will participate. All the project-specific information and agreements are mentioned in ‘annexes’. In those annexes you can determine start and end-date, specific terms and conditions for using a certain device, the costs that are related to this test and other issues. The annex also allows embedding bilateral contracts signed between a test-user and a company that is offering a service. This offers a way to deal with certain liability and insurance issues ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The contract is made in double (one for the test-user and one for the Living Lab). Both parties do sign the contract before the deployment of the project or handing over test-devices… Each time the user is ‘recruited and activated’ for a project in the Living Lab, only an additional annex has to be made up, with project specific data. This will then be added to the basic contract. Development: This contract template is contributed by IBBT and serves as a “good practice”. It has been used within the homecare and independent living experiment.

7.13 Community reporting tool

Issue: A community reporter is a person or group who uses media technologies to report about the community (e.g. within a city) and establish a community dialogue. There is a need for a toolkit which supports the set up of a community reporters group, recommends about social media tools that can be used, and provides training. Solution: This method describe how to set up a community reporters group: what are the important factors to consider, how to motivate participants, what are the free tools you can use (e.g. social media tools, blogging), and what are the cultural variables to consider when you try to train people on becoming Community Reporters. Development: The approach is developed in the eParticipation pilot.

7.14 Data protection template

Issue: In the frame of any research, it is preferable for some ethical rules to be followed. Besides the legal requirement for researchers to respect the laws protecting the study participants (consent, information, privacy, etc.), it is required to seek to apply these ethical rules, in an effort of respect for dignity and freedom of participants, for the commitment of the experimenters and recipients, and regarding the activities of the latter. Indeed, the application of such rules, fuelled by an everpresent ethical reflection, allows not only to ensure the proper conduct of the study and its aftermath, but also to pave the way for optimal experiments in the future. It is therefore appropriate to ensure that participants are better informed about their participation and different implications it entails, in a concern of goodwill and disclosure. Solution: The data protection template covers the protection of individuals with regard to processing of personal data and free movement of such data, as proposed in Directive 95/46/EC of the European Parliament and of the Council of 24. The template identifies: • • • •

The technology tested.

Interests of participants. The role of subjects.

The nature of collected data.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • •

Identity of experimenters. Recipients of data.

Rights of the participants.

The applicable legal framework.

Development: Developed in the eParticipation pilot.

7.15 Sub-license agreement

Issue: To facilitate the work of an SME during a pilot another SME may make available a technology or software. A formal agreement is needed between the two (competitor) SMEs, in the form of a sub-license agreement. Solution: The sub-license agreement template covers a number of issues: • • • • • •

Intellectual property rights. Grant conditions. Liability.

Confidentiality. Termination.

Applicable laws.

Development: The sub license agreement was made available in the eParticipation pilot, by Manchester City Council. This agreement can be re-used for other pilots in whom an SME needs to sub-license part of his work to another SME.

7.16 Cross-border application development

Issue: There is a need for guidelines to set-up cross border experimentation in the future. The aim is to overcome the typical problems that arise when distributed teams develop [an] application[s] together: how to share source code, assets and resources; how to setup an automated and swift build process when dealing with different technologies; how to execute technical project management: issue tracking, progress tracking and release cycle scheduling. Solution: The method consists of a number of tools, best practices and recommendations: • • •

Collaborative project management service (CPMS) Version control system (VCS)

SCRUM, which is a methodology for technical project management. A full explanation goes beyond the scope of this section, but there are a very large number of resources to be found on the subject. We definitely recommend delving deeper into the matter, since a strict adherence to the methodology is imperative for its success.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The idea of SCRUM is to have empirical process control. Actual project progress determines the planning and scheduling of the next phase of project advancement. It consists of an undetermined (i.e. project and progress dependent) number of recurring iterations with a strict time range and rigorous practices in order to allow a project’s direction to be steered based on actual, completed work, not forecasting or speculation. Especially important in SCRUM is a division of specific roles with particular responsibilities that represent the various possible interest groups: product owner (PO), scrum master (SM) and team member (TM). The PO is a proxy for the customer and stake holders. His main interest is the actual end result. The TM’s are responsible for the production of the application and consist of developers, designers, testers etc. The SM is the mediator between the PO and the TM’s; he’s the controller of the actual SCRUM process and the TM’s adherence to its methods. He’s also responsible for clearing any obstacles the TM’s might have that are straining the achievement of the agreed upon goals.

The main gist of SCRUM is to develop the application in a number of rounds (“sprints”). The final result of a sprint is always a potentially shippable product (“demo”). In the sprint planning meeting the PO, SM and TM’s determine together what the demo at the end of that sprint will exist of and what features of the final, full product will be included, by ascertaining the tasks at hand and their impact on TM workload. During the sprint (the actual development) the TM’s report to the SM by way of daily meetings (“stand-ups”) in which they, very shortly, list out their progress, challenges and requirements in order to proceed. If problems arise it’s the SM’s job to solve them. At the end of a sprint a demo is shown to the PO and possibly other stake holders. Afterwards, during an evaluation of the demo (“sprint retrospective”) the entire team discusses the encountered issues, and what could be learned from them.

An important element in the SCRUM methodology is the use of a whiteboard, where tasks are listed and their progress is reported. With distributed teams a virtual, digital whiteboard is essential. Some of the CPMS hosts provide a number of services and tools that together form such a whiteboard. For instance assembla.com foresees stand-ups and tasks (tickets) that integrate well with the VCS’s they offer.

Development: eParticipation pilot.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8. Collaboration Practices and Guidelines for Living Labs Networking 8.1 Introduction 8.1.1 Collaboration in cross-border Living Labs networks The topic of collaboration is at the heart of cross-border living Labs networking. APOLLON methodology development aims to provide the supporting methods, tools and guidelines for the various elements of collaboration in cross-border living labs settings. In this chapter, we focus more explicitly on the collaboration and governance models that support the living labs networking for enabling SME innovation. In elaborating the collaboration and governance models, we address the harmonisation and interoperability challenges in the pilot experiments. After analyzing the collaboration processes within the four cross border living lab pilot experiments we formulate recommendations on how to structure and support coillaboration.

Organisational frameworks and collaboration models are needed to establish, plan and govern the living labs network as a sustainable entity and to run the crossborder living labs activities. In this sense, collaboration and organizational arrangements are part of the network development phases of setting up, planning and running the living lab network. We are elaborating the organisational and cooperation aspects in more detail while taking in account the following: â&#x20AC;˘

â&#x20AC;˘

Collaboration Phases. We distinguish different needs, structures, processes and tools of collaboration as the cross-border networking proceeds across all the phases of cross-border living labs network development. Collaboration differs across the connect, plan and engage, and support phases. Collaboration Types. Collaboration types can be distinguished according to structure, process and tools. In terms of structure we address collaboration arrangement types such as partnerships, business models and contracts. Collaboration in terms of process includes, among other, the support of teamwork in distributed settings, and processes of coordination and management. Collaboration in terms of tools includes the use of asynchronous or synchronous communication tools in physical or virtual settings. Examples of such tools include collaborative workspaces (CSCW), multimedia conferencing tools, group blogging tools, meeting support, and web 2.0-based social networking tools.

Table 8-1 presents a simplified categorization of collaboration support based on collaboration phase (connect, plan and engage, support and govern) and collaboration types (structure, process and tools). Type

Phase

Connect

ICT PSP Project Reporting

Plan, and Engage

Support and Govern

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Structuring collaboration

Business models IPR and access agreements Business proposition

Contractual agreements Project plans

Collaboration process support

Brainstorming Negotiation Trust building

Negotiation of agreements Planning Matchmaking

Collaboration tools

Meeting support Conferencing Community building software

Meeting support Conferencing tools Collaborative workspaces Matchmaking tools

Project governance frameworks Project management rules Rules for accessing resources

Collaborative innovation User-developer interactions Project team collaboration Knowledge and info sharing Collaborative workspace Group blogging Conferencing Business collaboration platforms

Table 8-1 Collaboration across the phases of living lab development (with examples)

Some of the frameworks, models, methods and tools aiming explicitly to support cross border living labs collaboration have been discussed in previous chapters:

• • • • • • •

Business models for cross-border partnerships and value networks Contractual agreements Collaboration platform and other tools for project support Project governance methods Project management models Collaboration models and participative design during living labs innovation Business collaboration platforms.

8.1.2 Previous work on collaboration

Collaboration and collaborative support, for example within collaborative work environments, is an important topic of research and outcomes are of high practical value. For CSCW (Computer Supported Collaborative Work), much work has been done on developing software to support collaboration tasks, especially in groups (“groupware”) as visualized in Fig. 8-1. Behavioral aspects in collaborative working and in using collaboration tools within distributed collaboration and team workspaces have met a lot of attention, as well as topics of wider relevance such as collaboration culture and strategy.

A highly important topic in structuring and governing collaboration among partners is business model development. Osterwalder’s CANVAS model specifies the different elements of business models. Besides, common methods, tools and procedures that aim to structure collaboration include project planning, project management approaches and other.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Fig. 8-1: Groupware matrix (http://en.wikipedia.org/wiki/Computer-supported_cooperative_work) 4

Within the FP6 and FP7, projects such as ECOLEAD, Ecospace, C@R, Laboranova and COIN have explicitly worked on concepts, collaboration tools and platforms and processes to support collaboration in distributed teams, networks and communities. Also other aspects that are highly relevant for APOLLON are covered as presented in Table 8-2. For example, the ECOLEAD project has resulted in a comprehensive set of concepts aiming to support collaboration in different types of collaborative networks. Method, tool, guidelines, concepts

FP6 or FP7 Project

Platform and software services and tools to facilitate collaborative working

ECOSPACE, C@R

Action research innovation methodology: structuring the innovation process enabling co-creative innovation and problem solving, user involvement

C@R, ECOSPACE

Partnering, Contracting, IPR management concepts and methodologies in Collaborative Networked Organisations Tools for creativity support in groups and networks

Enterprise collaboration and interoperability services

Table 8-2. Methods and tools from other projects

ECOLEAD

LABORANOVA

COIN

8.1.3 Collaboration aspects in the APOLLON pilot settings Setting up, planning and operating cross-border networks of living labs is a complex process. For this to be successful, collaboration among the different parties involved 4

See also: Grudin, J. (1994). "Computer-Supported Cooperative Work: History and Focus". Computer 27 (5): 19â&#x20AC;&#x201C;26.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

and during the different phases is critical. Such parties include the living labs in the different countries, as well as the involved SME’s, large companies, and local stakeholders such as stakeholders in the thematic domain of innovation (e.g. healthcare institutions), as well as innovation agencies and municipalities. This chapter focuses on the guidelines for collaboration that we are able to propose based on the evaluation of the different APOLLON pilots and the evaluation of the collaboration processes encountered in these pilots.

Collaboration can be considered as a critical process in setting up, planning and managing a cross-border network of living labs. Collaboration is a process of working together among different actors to achieve a common goal. Collaboration support is diverse and includes organizational arrangements, suitable processes of interaction, communication and coordination, and effective collaboration tools. And also the existence of a “collaborative culture” and of “collaboration capabilities” are important conditions for success. Different contexts, exemplified by the different situational characteristics of the pilot environments, will require different approaches to providing effective collaborative support. APOLLON pilots present four different sets of challenges and situational contexts, which may give rise to a diversity approaches and requirements to collaboration (although we also may expect similarities). Our goal is to identify collaboration guidelines that are addressing these different contexts and challenges and contribute to identifying recommendations and requirements for new cross border initiatives. Next section first introduce an analytical framework for collaboration analysis. This framework is applied to the four pilot environments in order to acquire insight in actual collaboration processes, what facilitates these processes and what the bottlenecks are. The chapter then continues by analyzing collaboration processes and outcomes in a cross-pilot comparison. Based on this analysis, lessons learned are summarized and guidelines for collaboration support are proposed.

8.2 Analytical framework for collaboration analysis

This section introduces a simple framework for analysis of collaboration processes and collaboration support in creating, planning and operating cross-border living labs networks (Table 8-1). The role of the framework is to facilitate investigation of the descriptive (understanding-related) as well as normative (recommendationsrelated) aspects of cross border living labs collaboration. The framework is a matrix consisting of two dimensions. The first dimension is the phased development of the cross-border living labs network, through phases of connect, planning and operating a network of living labs. The second dimension denotes the level and scope of collaboration. A distinction is made between the strategic and the operational level of collaboration. The strategic level of collaboration ensures the creation of collaboration conditions and provides a generic direction to the unfolding collaboration. For example “agreement on a business model” defines the roles and obligations of all collaboration partners. The operational level focuses on implementing and guiding the collaboration in the practical situation. Table 8-3 also presents a number of examples of issues that are covered within the pilots. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Phases

Connect phase

Planning phase

Operation phase

Scope of collaboration Strategic aspects of collaboration

•

Operational aspects of collaboration

•

Agreement finding about common goals and approach

Dialogue building and general negotiation support Business models, IP handling

Collaboration procedures, processes and tools for connect phase

E.g. Internet-based tools for communication and exchange

•

• • •

•

Organizing the cross border living lab planning and development process

Partnership structuring, contracting frameworks Elaborating a common plan and approach Network planning processes and procedures

Tools for collaborating in the planning phase, e.g. using shared workspaces

•

Responsibilities, governance models structuring living labs operation in the network

Processes and tools for project management and coordination

Processes and tools for living labs collaboration, e.g. web tools, shared workspace

Table 8-3: Analytical framework for collaboration analysis

This analytical framework aims to enable an analysis of two sets of questions, one descriptive and the other normative: 1) How is collaboration actually set up in practice, how has collaboration been supported, and how has collaboration worked out in terms of efficiency and effectiveness when it comes to resolving the identified collaboration bottlenecks?

2) Which lessons can be learned regarding collaboration and collaboration support, and which recommendations and guidelines can be provided to enhance collaboration?

Collaboration support may include process support, organizational frameworks as well as collaboration tools. The term “collaborative network” is reserved for collaboration between all partners: living labs, SMEs, large companies, and local stakeholders such as agencies and municipalities. The term “Living labs network” is reserved for the involved living labs only. A “domain network” denotes the wider network of actors in a domain (such as healthcare, manufacturing) which acts as a breeding ground of ideas and projects. A “project network” includes the collection of partners that share a common goal which is defined in an agreed plan.

The next sections present an analysis of collaboration processes in the four pilot environments. The main aspects covered are: 1. Short characterization of the pilot, 2. Characterization of collaboration aspects, 3. Identification of collaboration bottlenecks and specific characteristics, 4. Collaboration support, 5. Lessons learned.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8.3 Homecare and independent living: collaboration for technology transfer 8.3.1 Pilot context The Homecare and independent living pilot explores the cross-border transfer of technologies and systems from one location to another cross border. Two different experiments, each with two living labs in two different countries involved, have been undertaken.

1) The first experiment is transfer of a videophony solution called Xtramira developed by Televic compatible with existing personal alarm systems from Belgium (IBBT living lab) to the Healthy Herttoniemi living lab in Finland (receiving Living Lab). The problems that had to be dealt with included the issue that existing technology was not applicable in Finland due to differences in tech standards.

2) In the second experiment a network of sensors and intelligent computational techniques is used to measure “activities of daily living” by elderly or sick people as a way of remote health monitoring. This case includes the transfer of an existing system developed by Innoviting, The Netherlands, to the living lab Salud Andalusia (Iavantes).

A common characteristic of the two cases is that the key issue is on the transfer of a homecare technology solution from one location to the other, cross border. This not only requires technology adaptation to local circumstances but also the construction or adaptation of a local ecosystem in the “receiving” country, including the different actors and roles of a value chain around the technology solution. The health sector is strongly determined by locally specific value chains and regulations and technological platforms. 8.3.2 Cross-border collaboration issues

The main cross-border issues in this pilot requiring collaboration include the adaptation of the technology system to local conditions, as well as resolving legal issues such as related to access policies with regard to personal data and profiles. Each living lab has their own ecosystem with stakeholders and users. As the health sector is strongly determined by local specific value chains and regulations, the living labs investigate the required ecosystem and approach for successful replication and to assess its role within the cross border networking.

The overall objective of the cross-border experiments was to investigate the required eco-system and related conditions for successfully transferring solutions of SMEs from one to another context, using the living lab as a local hub. Successful replication requires insights in the nature of the eco-system to be created in the new market, in to what extent the already existing ecosystem should be adapted, and in how the transformation should be managed. Methodological challenges in supporting the transfer included (a) how to set-up a similar eco-system and finding the right partners for testing a similar business model, (b) assessing the impact of ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

such transfer on SMEs technology as well as operational activities and (c) investigating the limits of Living Labs existing role which is mainly locally oriented.

The first step was to investigate and define the necessary requirements to establish the transfer. Such assessment was performed on three levels. At the technologically level it was examined how the set-up and service needed to adjust (translations, plugs, connectivity and other issues). On the research level it was focused on user participation needs and on how to evaluate user feedback. Finally, eco-system requirements were investigated, for example which parties were to be involved, how to define roles and responsibilities, and which contextual elements (e.g. legislation and health organisation) should be taken into account.

The second step, based on this requirement analysis, was to develop a common approach and process concerning the cross-border pilots experiments. Main focus was on the overall processes with regard to the experimentation, and on the business model. This included not only operational activities but also to specific research goals, business objectives and contextual factors. Once the general processes and principles of working were clarified the preparatory transfer work was started. This was done on the local level, e.g. each SME adjusted their technologies in their own lab while the remote partners (Living Labs) would set-up the required technical infrastructure and engage users. One of the most important activities during this phase was identifying and engaging the relevant, local stakeholders that are willing to participate and collaborate. Especially within a health-related context the involvement of supporting, cooperative partners is a necessity.

The third step included preliminary in house-testing and training. This was needed to ensure proper functioning of the technologies and protocols. In addition the data collection that supports the various research objectives and evaluations was set up. Test users were recruited, activated and profiled. During live operation of the pilot in which technologies are used in a real life setting, various evaluation moments are foreseen in order to detect any issues swiftly acting as input for the iterative development cycles. For the latter, the user input is analysed and transferred towards the different partners, adjustments are made and the revised technology is immediately again transferred into the Living lab. In the cross-border set-up of the Living Lab projects a Living Lab centred approach is followed. This means that the Living Labs both at the home and remote locations play a critical role. Not only these living labs act as the â&#x20AC;&#x153;hubâ&#x20AC;? for the SMEs, they also perform most of the set-up and execution activities of the cross-border project.

The transfer of the homecare services from one market or ecosystem to another has provided useful insights in cross-border living lab activities. First of all, regarding cross-border experiments it was noticed that it is difficult working with one fixed method. Although the different phases of the overall Apollon methodology cover the necessary steps and aspects, the operationalization and implementation differs from experiment to experiment. Therefore, a common cross-border methodology is ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

feasible only at a generic level. Secondly, it is important that in the identification of requirements special attention is given to the specific business requirements of the involved stakeholders. Especially when working with SMEs one has to ensure that the activities of the cross-border project are fully in line with the company’s existing roadmap. If this is too much ‘off-track’ it will be very difficult to engage (local) stakeholders to participate and invest in such a project. This is important in setting the scope of joint projects and is crucial during the connect phase. Therefore, a good understanding and agreement among all partners is necessary before entering a new phase. Third, if an SME wants to enter a new and unknown market, it relies on the local living lab for providing them the necessary contextual information and to do the matchmaking with local stakeholders. This offers a challenge to the current role of Living Labs as facilitators towards a more development oriented role, which implies a different set of processes, methods and tools to enable them to address these demands. Fourth, from a more operational point of view we noticed that a cross-border activity requires an intensive communication and tracking role, again requiring suitable processes, methods and tools.

Regarding the eco-system, two main aspects should be noticed. First, due to the large differences in how the health sector is organized in each region as well as due to the diversity of the Living Lab structures, the creation of a common eco-system between those Living Labs will be highly difficult or even impossible. Second, the eco-system cannot be approached in an unilateral way. It is not sufficient to have the same type of partners on board. The eco-system also applies on other levels such a legal aspects, technological conditions and cultural differences. In preparing successful cross-border living labs networks, all these aspects should be dealt with. 8.3.3 Collaboration bottlenecks

The main collaboration issues encountered in the homecare and independent living pilot were the following: •

•

Creating a “receiving” local ecosystem, including a sustainable collaboration between different parties. This also requires the agreement about a common business model, and resolving various local regulatory and legal issues.

Establishing a collaboration between the “sending” living lab and involved SMEs, and the “receiving” Living Lab and local ecosystem. This collaboration is built upon an agreed project plan and agreements between all parties involved. Finding the right partners or stakeholders. Finding the right partners or stakeholders is not always easy, especially in the healthcare domain. The role of the partner should clearly be stated and should be much aligned with their daily operations or future roadmap. Funding or extra resources are in that sense either an enabler or, by the lack of them, a huge bottleneck.

Creating a shared vision and expectation of all the involved partners which is based on their needs, interests and motives. There should be clearly identified value for each partner involved.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

From the project set-up it is needed to have a good and clear overview of the roles and responsibilities that are required and who is able to fulfill those. This, together with the above, is a necessary step to approach the appropriate partner and to set the right expectations. If this is not clear, partners may have different interpretations and expectations of the project that can lead to major issues in the course of the project such as tasks not being fulfilled or partners dropping out due to different vision. Therefore careful expectation management is recommended in order to establish a good common understanding of the needs, interests and results.

In the phase of creating the network (connect), identifying the right needs of the partners was found difficult. Finding partners who were having the common interest and needs was a problem. Within the context of the Apollon project participants are not always participating in line with their immediate interests. Another problem was to acquire a good understanding of the scope and the objectives of pilot partners. Also, funding of the network partners is a bottleneck as costs of SME partners not acting as consortium partners cannot be covered.

Communication was found as one of the most crucial elements throughout the whole process of establishing cross-border collaboration. As a face-to-face communication is still identified as the most effective method, it is rather difficult (timely and expensive) to do this within a cross-border context. Another element is that when local actors are not a core-partner or are only partially involved, therefore communication often goes through a central stakeholder (who is a keypartner in the project e.g. the Living Lab). They will act as a gateway and dispatch between the project or network and the local stakeholders, due to different reasons. Although this approach has its benefits, we do see that the lack of direct communication and interaction between the partners (e.g. originating SME and potential partner in other country) can create big problems in the set-up and deployment of the project.

In addition, especially in relation to the planning and engage, we do see that the contextual differences between the local and remote context (eg. receiving and sending ecosystem) always raises various issues that are unexpected and unforeseen. Therefore the pilot sometimes needs to be adjusted in such a way that is not in line with the expectations of the partners. Due to the complex structure, specific legal and ethical issues within the health, homecare and independent living domain, this is a potential risk to identify and address upfront.

Finally, and this relates with some of the elements within the connect phase, an important element in the plan and engage phase is the willingness and ability of the partners to do so. Within the homecare and independent living domain, most actors are working very locally due to the nature of their services and target audience. Often their activities are focused on the local market, and by so their operations. Participating in a cross-border pilot requires a change in their organisation that they have not envisioned initially, for example how to provide remote support and how to organise local representation. In order to deploy a cross-border pilot properly the partners that are collaborating will have a clear motivation to do activities beyond ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

their own market. This has still to be the case after the project itself. The project on itself cannot be the main driver for a stakeholder to participate.

In the phase of operating the network the encountered problems were mainly connected to the contextual elements issues that were not foreseen prior to the deployment of the pilot. This would require the ability to adjust during the pilot and to provide the necessary support to the various stakeholders. Often the amount of effort that is required to do so, is underestimated and/or not budget properly. Especially when transferring an existing service there is the misconception that the service works, that it is proven and that the transfer itself is just a replication. This was not the case, it required adaptation and these adjustments brought along unforeseen problems. Moreover, when setting up cross-border pilots and engaging new partners during the course of the project one has to ensure that the expectations and interest of all are still aligned. In other words, new partners has to be fully informed and aware of the common goals, expectation and roles that were set at the connect phase. It is important that new expectations are not created, requests re-focus or a too much additional efforts so that the support can be guaranteed. Another problem in the collaboration, and especially within the support phase, is working with multi-disciplinary teams of members having different backgrounds and understanding. This can lead to miscommunication and misconception resulting in not providing the right support, information or even service delivery. This is also associated with many times implicitly presented knowledge and with wrong assumptions that other partners have the same information or reference frame. Therefore it is of great importance to explicitly present issues, information, and knowledge as detailed as possible. 8.3.4 Collaboration support

In setting up cross-border collaboration we have been creating and using various methods and techniques that helped us to address the above issues. We have noticed that each of these methods has their value, but that a combination of them offers the best result. The main approaches that were used to enhance the collaboration include the agreement on common goals, the use of management approaches and using communication tools. Requirements analysis, continuously adjusted based on new insights and lessons learned, has been partially effective in identifying contextual elements. The requirements analysis is a very good method in the initial phase as well as throughout the pilot as reference document. This was mainly helpful to identify other requirements besides the technical ones, for example as regards contextual requirements. However, the level of description was often not detailed enough so still too many implicit assumptions were held (eg. broadband connection doesnâ&#x20AC;&#x2122;t have the same standards). There is a need to describe various elements into much more detail. To a certain extent, value analysis was applied in order to map stakeholder objectives but the need was identified only during the course of the project. The fact that this was not performed in a systematic way at the beginning of the project lead to some mismatches in the different objectives of the partners. Regular conference calls have been held for project ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

internal collaboration. The living lab also played a role in ensuring collaboration as it was arranging matchmaking and local partnerships, acting as an orchestrator and trusted party. This worked well for matchmaking and partnerships, but a direct link with SMEs was lacking. It is important that the Living Lab plays a local gateway role but at the same time has to try to connect the partners as soon as possible in the process. This is also related to the fact that a good ecosystem analysis is needed in which the roles and responsibilities are clearly defined and in which the organisational and process arrangements are reflected. This has to act as a reference document throughout the whole project. Finally, it is important to communicate on a very regular base, not only between specific partners that are working on a specific issue, but with all project partners. Being up-to-date and being aware of what is going in the pilot and network is extremely important as the elements are interconnected. 8.3.5 Lessons learned and collaboration guidelines

To enhance the collaboration between the partners it is recommended that first of all there is a clear win/win for all parties involved. This means that the participation of a partner has to be driven by a specific need and goal. These objectives and expectations need to be made explicit and communicated to all partners. Second, in addition to this, it will have to be made sure that the goals and needs are framed within the daily operations or in a specific roadmap of the SMEs and additional partners. If not, the motivation and willingness to collaborate and to adjust during the pilot will be limited. Subsequently and thirdly it is necessary that this willingness is also reflected in an identified business opportunity after the completion of the project. In other words, if the results of the pilot clearly indicates an added value, that the partners have an honest interest in the continuation (on a commercial base). Fourth, to enhance the collaboration, you should try to demonstrate or visualize as much as possible the systems and services. A good and detailed description creates a certain mind-set and even expectations, when working with (live) demos, it is much easier for all partners to grasp the real capabilities of the product or service. This will reduce the amount of misconceptions or wrong expectations. Finally, especially in the domain of homecare and independent living, pilots require a high level of maturity. The level of experimentation within the pilot itself is limited. Therefore you will need to pay extra attention to make sure that everything functions, that all partners deliver. In addition you will need to map the potential risk factors. Phases

Connect (inception)

Planning, developing

Operating (running)

No business models prior to the pilot implementation. No IP handling Requirements analysis Technical and contextual requirements (a reference

Organizational requirements Research setup definition Research coordination definition Research coordination

Document on organizational requirements (transferring Living lab) Research coordination definition Sharing & Dissemination

Levels / aspects Strategic aspects of collaboration

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Operational aspects of collaboration

ABSTRACT

document) Eco-systems analysis (stakeholder identification, role assignment, tasks assignment)

Research on legal & regulatory issues Cross-border issues

definition Value analysis

Documented identification of requirements (transferring Living lab) Requirements for identification of stakeholders (receiving Living lab) Assign SPOC for each Living lab Technology & service transfer definition (SME) Definition of dissemination & sharing (methods & tools)

Assigning roles within the CB LL network (transferring LL) Research framework setup (transferring LL) Questionnaires (transferring LL) Topics list for interviews (transferring LL) Provide access to LLADA platform (transferring LL) Data generation methods definition (both LL) Definition of interaction of stakeholders within ecosystem (receiving LL) Definition of POST MEASUREMENT (both LL)

Face to face meetings of transferring Livig lab, receiving Living lab, SME and other stakeholders (partners in the remote eco-system)

Workshops; Training sessions; Discussions; Focus groups; Interview topics; Questionaire preparation

Supervise of the CB LL network (transferring LL) Regular staff meetings Regular conf calls (reporting to transferring LL) Research plan execution (receiving LL) Topics list for interviews adjustment (receiving LL) Selection of stakeholders (receiving LL) Selection of end-users (purposeful sampling) (receiving LL) In-depth profiling of stakeholders – ZERO MEASURE (intake interview by receiving LL, based on transferring LL) LLADA platform (different level of access for different stakeholders within ecosystem) MyBBT platform

Table 8-4: Collaboration analysis for the Xtramira pilot

Methods & Tools: Surveys; Interviews; User observation; Ishikawa fishbone diagrams; Mindmap diagrams; Project diaries; Laboranova communication toolset; LLAD; MyBBT; Skype; E-mail; Face-to-face meetings

In summary, the main lessons learned and guidelines that can be proposed regarding collaboration include the following: • • • • •

Ensure win/win for all parties involved

Make sure that pilot is in roadmap of SMEs and additional partners Identify business after project completion

Demonstrate and visualize tangible systems and technologies, results

Address the risk factors that are critical for project success, do not experiment too much in healthcare.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8.4 Energy efficiency: cross-border exchange of knowledge and information 8.4.1 Pilot environment The Energy Efficiency pilot in APOLLON comprises four energy efficiency living labs experiments in four different countries: Sweden, Finland, Netherlands and Portugal. The focus of this pilot and its experiments is mostly on data, knowledge and results sharing. Additionally focus is on collaboration among SMEs and the benefits for SMEs to participate in a cross border living lab network in order to expand business.

The Energy Efficiency pilot sets out to test, to evaluate and to validate the process of extending the market for SMEs operating with products and services in Energy Efficiency. The pilot projects are operating in a fragmented market all over Europe, something that was to be analysed in the APOLLON project, in order to be able to come up with suggestions on best practice solutions and recommendations. In order to address these specific issues the Energy Efficiency experiment followed the following steps: 1. Preparation of the pilot: the Living Labs shared best practices and methods for user testing, and co-created a methodology for the Energy Efficiency domain. Technologies to be used were agreed for the four pilots. 2. Experimental setting: the technologies were installed. 3. Testing: here end-users were involved in a participative innovation process. 4. Evaluation: ongoing throughout the project.

In Amsterdam the pilot is called the Amsterdam Smart City, an initiative that tackles the key challenge for sustainability programs and smart grid development. The pilot area covers two city parts of Amsterdam and involves about 1250 households. Selected households from this area were included into APOLLON demonstrations. The focus was in activities for a sustainable living in social and supported housing, aiming at reducing the energy consumption in households via innovative products, services and techniques, including smart meters, energy control mechanisms, direct feedback and information provisioning etc. It deals both gaining is insights in usage behaviour as well as raising awareness and achieving behavioural change. The intention for the cross-border pilot was to test technology from all partner countries in Amsterdam, and that Amsterdam would provide infrastructure for SMEs in other countries to test their technologies.

The Finland pilot tackled the potential and hurdles of apartment level real-time measuring. The objectives were a) to promote innovative ICT solutions for energy management and communication and to study sustainable user behaviour change and mechanisms related to it, and b) to create new services and understand the energy controls from the user perspective. Systems were set up, that allowed monitoring real time energy consumption at building and apartment level, and which communicated this information through web and mobile services. Users could see their real life energy consumption and a set of suggestions on how to reduce their energy bill. The partners consisted of Aalto Living Lab, Nokia, Metropolia, HSE and Process Vision, and they were supported by City of Helsinki, ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Helsinki Energy and Green Net Finland. The SME’s involved are Process Vision and There Corporation. The Lisbon pilot key objective was to promote higher energy efficiency in residential buildings where the householders are strongly motivated for energy saving and energy efficient use, by using ICT technologies and actively promoting user behaviour change. Of interest was also to enhance user behavior change and focus on the consumption reductions that can be achieved through a dynamic and consistent information campaign, and by provision of access to real time data on energy consumptions and actions to perform according to the information displayed.

The Luleå pilot, finally, involved the Luleå House of Culture, which is connected to district heating and to the district cooling system that works with the nature, using cold water from the river. The heat dump is in the town bay. The building has a high level energy management system but aim to achieve more energy savings involving and promoting users’ awareness. The Luleå team intended to divide the building in to different improvement different areas that was equipped with the necessary measurement meters. In focus was to measure how/if the user behaviour is changed by the introduction of different methods to help the visitors take the right decision, e.g. by opening the doors manually, instead of using the automatic door opener. The idea for the cross-border pilot was to perform several tests across borders to learn about each other’s products, and each other’s local tests. 8.4.2 Cross-border collaboration issues

There have been different types of collaboration in the APOLLON project. Considering that the main result from APOLLON should be positive impacts of crossborder living lab networks, the focus here is on this cross-border collaboration, and collaboration between Living Labs and SME’s at local level is not included. It will, however, be commented on since there was an intention to involve these businesses in the cross-border collaboration, something that did not succeed. APOLLON aims to generate guidelines for and offer a model to collaborate between partners in the project. Within the Energy Efficiency pilot there have been SME’s involved although they have not been formal partners in the project. Initially the idea was that also these SME’s should take part in cross-border collaboration. However, the fact that they have not been formal partners showed up to be an obstacle hard to overcome. This has led to “a lot of unsuccessful negotiations” in the context of this pilot.

In this endeavour to create cross-border collaboration between Living Labs and SME’s in different countries, it is the Living Labs that have been the driving force. This is, according to one task-leader, a disadvantage; it would probably have worked out better if it was the SME’s themselves that pursued the collaboration. There have been attempts, e.g. by Botnia Living Lab in Sweden, to transfer the responsibility for running the pilots on the SME’s, and instead provide support in this process, ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

something that did not go well. Instead the SME’s have had as their role to provide technologies for the pilots.

There have also been attempts to carry out experiments across borders, but neither this did succeed. The reasons for this are partly technological – some solutions were developed for an environment built on gas, not electricity; and the experiments have used prototypes, not fully developed products. One example is the Luleå experiment, which received a prototype from the Netherlands to test, which showed up to not function at all in the Luleå setting. Another reason is organizational – in the APOLLON project there are SME’s that have not received any allocated budget for their participation, which in turn resulted in that they directed their main focus on their own day-to-day business.

Within the pilots the collaboration mainly happens in meetings, and via e-mail, and it is in this way tasks and responsibilities are divided among partners. The collaboration between pilots (i.e. more cross-border) did not function well; e.g. there is no collaboration between the SME’s in Lisbon, Amsterdam, Helsinki and Luleå in this respect. What mainly has enforced the collaboration is the common task and mission of the experiments within the over-all pilot. Overall, collaboration has taken place around a diverse set of topics and issues: administrative issues; development of tools (project work); documentation; negotiations (with SME’s); technological equipment; change of behaviour; energy consumption issues; sharing of methods, tools, and knowledge; research framework; communication tools; workshops and roadshows. Connect phase collaboration

Much of the collaboration taking place in this pilot is planned and organized for already in phase of developing the APOLLON project’s Description of Work (DoW). There it is stated who is supposed to collaborate with whom. Hence, the connect phase was already carried out before the actual pilot started and before experiments was to start. Instead, contacting and connecting with other partners for the pilot and experiments was just a question of deciding where, when and how to meet. Responsible for this was the Living Labs in each country, with an overall responsibility for the pilot leader organisation (Alfamicro), in collaboration with the pilot task leaders. The latter have been responsible for setting up meetings and planning the work etc. for their respective tasks. The tools used for conducting this step included face-to-face meetings, e-mail, ordinary phones and Skype. Collaboration during the planning, developing phase

In order to be able to carry out the cross-border large scale demonstration, and address relevant issues in the Energy Efficiency pilot, the pilot responsible people planned the pilot by addressing the following four steps; Preparation – Experimental setting – Testing – Evaluation. The intention was to “set the scene” and reach a common methodology, determine what actions to optimize, and agree on common technologies for the four pilots. The tools used for conducting this step ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

include face-to-face meetings; e-mail; ordinary phones and Skype; documentation and literature; seminars and conferences.

One method for collaboration which was not included in the planning from the start is the Roadshow, thus this method has been developed in setting up and conducting the pilot. The underlying trigger was the importance of face-to-face meetings. The Roadshow was used in the beginning of the project, and took place in all four countries. It was the Living Labs who arranged the Roadshows and invited different, what they believed were relevant, stakeholders that in some way are active in the energy area. The basic idea was that the SME’s would get the opportunity to demonstrate their products and services, get contacts, and thus expand their network. Also, the objective was to raise interest for both the APOLLON project and the SME’s. The lesson learned is that it is vital who exactly is invited. The SME’s wanted to find new contacts and presumptive partners; instead they met competitors, something that was met with dissatisfaction. Instead, in the energy area, who should have been invited to the Roadshows are e.g. municipalities, and energy companies that provide electricity or gas. Furthermore, this method implies that the Energy Efficiency pilot has also invited stakeholders that are not partners in the APOLLON project. Collaboration during the Operating phase

During the project, this pilot has been forced to slightly re-focus their work, as stated above. One consequence is that “nobody has really worked with a focus on the benchmarking framework”, said one task leader. Even so, the task leader believed that “it still is created, although in an unconscious process”. Another task leader meant that “a common research benchmarking… has been discussed for a year, but what has happened?” 5

During the operational phase the tools used include: face-to-face meetings; e-mail; ordinary phones (teleconferencing) and Skype; co-work on deliverables and documents. It is remarkable that the shared workspace platform (MyBBT) has been used only by administrative staff of the project.

Since the pilot aimed for a) real time tests with end-users, b) providing support and help to SME’s and c) creating a benchmarking framework, there are some methods that have been used for this purpose. These include the use of storylines (which contains questions and tasks to be prompted to the users taking part in the test); Questionnaires, and Focus groups. All of these methods have been used as methods for end-user involvement (hence, not cross-border), and behavioural change, thus, partly for collaborative reasons, and partly for data gathering.

Within the pilot, methods have been developed jointly to support knowledge exchange among partners and methods to create business opportunities. Overall it 5

Still, the task leaders believed that it will be reported (D3.4).

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

was decided to have three different types of collaboration activities, namely 1) business matching and partnerships (e.g. Roadshow; 2) technology testing (which required collaboration between many different actors in order to get the tests operational; the living lab designed the tests and SMEs provided technologies and was in direct contact with the user community); 3) Knowledge transfer; this has proved hard to accomplish, but is regarded as vital for success. Closing the collaboration

No specific planning for how to close the APOLLON project was expressed. Instead, it is already planned for a continuation of the ideas found in the experiments. As one task leader put it: “We see this as a point of departure, we’ll continue the project, go on working on user behavioural change, continue our testing and extend the project to involve more households.” 8.4.3 Collaboration bottlenecks

From the previous sections and from the general setup of this energy efficiency pilot it can be concluded that cross-border collaboration among living labs and SMEs has been fairly limited. The cross-border collaboration was mostly limited to exchange of knowledge, experience and methods (e.g. benchmarking of data) from the results of the different experiments in the pilots. Some of the reasons for this limited form of collaboration were the following: •

•

• •

The original purpose of the energy efficiency pilot, to test technology in cross border settings, was not realized. Reasons lie in the business interests of the different partners and the unclear set up, planning and objectives definition of this cross border pilot. The benchmark framework did never come off the ground. This implies that the different experiments in the countries involved were carried out mostly as single setting experiments, where no real need for cross-border collaboration even emerged.

Some attempts to carry out experiments cross-border did not succeed because of technology issues (prototypes not functioning in another location). Also there were financial and organisational reasons (SMEs having no budget within APOLLON).

Involved SMEs were not formal partners in the project, which led to unsuccessful negotiations, as indicated previously. The Living Labs were the driving force of activities in the pilot experiments, however it might have been better to provide more responsibility to SMEs. SMEs were now mostly in a role of providing technology to the pilot only.

8.4.4 Collaboration support

Collaboration support in the pilot is aligned with the needs within the pilot. As discussed the actual needs for collaboration were limited. One of the more successful ways of this limited form of collaboration as dissemination and exchange was the Roadshow. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Other methods or tools fulfilled a mostly technical role and cannot really be called “collaboration support” e.g. the storyline approach.

Regarding project collaboration tools, it is apparent that within this pilot the most commonly used are ordinary, well-established communication tools such as phone, e-mail and Skype. Remarkably, shared workspace was not used. Many times it was emphasized the importance of face-to-face meetings. Regarding the use of collaboration tools, it is not the phases (connect, plan and develop, operationalise, closing down) that indicate what method or tools that is most efficient to use but the pilot task and the task activities, together with what must be achieved that determine the selection of methods and tools. 8.4.5 Lessons learned

During the work within this pilot so far, several issues have been identified that need further elaboration. For example there is need for methods that increase the engagement level among project partners. Their observation is that this mainly concern SMEs – “it is difficult to engage SMEs in an EU project since there is such long project duration and things changes quickly in SMEs contexts and then the project do not make much sense. Also the SMEs involved in the project are not all of them interested to enter an international market with their product; their incentive for participating in the project is rather low.” 6 As one task leader expressed it: “SME’s environment is dynamic, and their main interest is to make business. APOLLON does not do this, and also, the SME’s find the project being slow and not reaching for their objectives. Therefore it is hard to gather and claim for their attention.” In particular, what has been identified as required or useful for cross-border collaboration is: • • • • • •

Methods and tools especially designed for collaboration in and between pilots.

Methods for sharing knowledge across borders between partners within the project. Establishment of the potential when several Living labs collaborate across borders. Methods for interchange of results. Guidelines for who owns the data. Methods for larger test groups.

Language is identified as an obstacle – it is hard to get all partners to understand what their expected contribution is, as well as to share experiences. The latter would be facilitated by more physical meetings focused on knowledge sharing. 6

WP3 3 Monthly Session Report, April-June, p. 13

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Here we want to mention also what, from the perspective of pilot participants, is regarded as needed or useful for collaboration with end-users (although this need not be a cross-border activity):

•

Methods that can help measure benefits and behavioural changes among users; Methods that create engagement among people.

When it comes to the problem of knowledge sharing, the pilot work suggests the development of a methodology that supports the design of user behaviour transformation studies. The methodology should have two aims, where the first is to support the design of user behaviour studies and the second aim is to share knowledge between partners within the experiments. The solution for the latter is workshops to be carried out in three steps; a first workshop was held in April 2011; a second a workshop in October 2011 and the last took place in December 2011. During these workshops the experiment leaders (Living Labs) were brought together and collected their experiences of carrying out user behaviour change studies. Within the pilot it is planned to gather the experiences into an overarching methodology for this kind of studies (D3.6). Another suggestion is the creation and use of similar processes, i.e. prepare deployment, research approach and data collection, sharing and analysis. The rationale for this is making it possible to compare and aggregate results. “Although different cross boarder activities might have specific dependencies, but the approach should be comparable at an overarching way, e.g. all Cross Border Activities should be evaluated using the same template. This makes it possible to compare them on the meta-level which the three cross-border Pilots (business, knowledge and technology transfer pilots) can be summarized and analysed on the meta-level.” 7 In connection to this is the need for support of the process of comparing results from the experiments.

The pilot also suggests participating projects to assign the transferring Living Labs as main supervisors to monitor the overall research work, coordinating both local and remote activities. A contact should be defined for each Living Lab, and these persons should constitute the user research task force.

APOLLON started with limited or no budget for technological equipment, something that made it difficult to carry out the tests. “It is hard for SME’s to provide equipment for no money,” said one task leader, and concluded that “you need money, time and human resources (in-house and international partners).” This was regarded as a big failure of the APOLLON project. Thus, it is important to address the following points: •

Budgets for acquisition of equipment, otherwise you have to work with what you have, and this does not generate good results.

WP3 3 Monthly Session Report, April-June, p. 18

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

Clarify every partner time frames. Big companies, SME’s and Living Labs (research oriented organizations) have different time frames, and this needs to be understood by all partners. Subcontracting.

Another lesson learned is that in the energy saving area, SME’s do not want to go abroad to test technologies that they can test in their own environment. For the moment, companies find growing markets in their own countries, and facing challenges in their homelands. Consequently, they rather choose to look after the domestic market, than going international.

Also, one task leader commented that methods and tools can be different, and they cannot be generalized to all Living Labs, there needs to be adaption of tools and methods to function with specific Living Labs. Based on the work in this pilot we can distinguish the following issues to consider for developing collaboration guidelines in cross-border living labs settings: •

•

Establish roles and responsibilities from the beginning. An attempt to carry out pilots in a similar way that has been done in APOLLON requires clarity around roles and responsibilities, it must be settled who will lead and administer the work. Within this pilot the intention was to let the SME’s take on this responsibility, something that did not succeed. Our interpretation is that these matters need to be established from the very beginning, since it showed up to be harder to hand over responsibility during the course of the project. Make sure that technology to be tested is compatible in different environments. Technology to be tested must be analysed and adapted for different environments in advance. There must be confidence that it will function regardless of test site.

Establish what activities the project will contain, and discuss and organize collaboration based on this. In this pilot, collaborations have taken place around a common activity, that is, it is the pilots that have driven the collaboration. Therefore, if collaboration is to function, the work in WP3 suggests that the easiest way to plan and accomplish this collaboration is to organize it around activities. Carefully analyse which stakeholders are relevant to invite. The experiences from the developed method, Roadshow, indicate the importance of carefully choosing what stakeholders to invite. Hence, the purpose, aim and objectives with the Roadshow must be clear.

Clarify each partner’s time frame, expectation and needs. Since different partners in a pilot have different aims and objectives, and different contexts, it is necessary to make sure that all involved are aware of the different partner’s specific time frames. This is important in order to guarantee that all the partners understand each other’s realities.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

It is preferable that all involved are formal partners in the project. In WP3 it showed up that it is hard to get SME’s participate on a voluntary basis, hence it is of great importance that every partner get the resources they need for taking part and contribute to the pilot.

8.5 eManufacturing: a common platform for business innovation 8.5.1 Pilot context

Within the eManufacturing pilot, a platform was set up with two core Living Labs and their partner SMEs in the cross border network of Living Labs. The use cases that have been selected realized real-life manufacturing scenarios dedicated to monitoring and optimizing certain production KPIs: monitoring of energy consumption, and status monitoring of assets in a plant. Moreover, the collaboration network was under investigation and both intra-regional SME interaction as well as trans-national SME interaction has been checked with real-world services and scenarios with respect to the technical services developed. A major component of this pilot was also to investigate if and how the Living Lab-specific SMEs are able to communicate and trade their services in a trans-national context.

The focus of the pilot is twofold: on research (Middleware for Device Integration platform prototype) and on cross-border collaboration focusing on the mentioned use cases. The cross border activities and their order that were executed for can be listed as follows: technical and business blueprint; technology knowledge transfer; use case implementation; use case execution; support and maintenance; joint requirements gathering on a cross-border collaboration platform. 8.5.2 Collaboration issues

As regards the Connect phase, the collection of partners already existed before the start of APOLLON. APOLLON a such was an important trigger for collaboration. Partner ISA was identified through APOLLON. Hungarian partner HVEC dropped out because of financial reasons. Collaboration during the connect phase was affected by the need to understanding the different partner backgrounds. Expressing the real business interests was found a problem. Also cultural issues such as different work and collaboration styles were affecting the actual collaboration. Additionally, the lack of funding of SMEs was a bottleneck for involvement into the pilot. During the Planning phase, it was found difficult to find the right level of contract needed. This also depends on the type of activity such as co-development, testing, installation or else. Again cultural issues were found affecting collaboration, for example in preparing the pilot planning. An issue is, for example, what to include in planning and the way of timing of activities. The German partners prefer a detailed planning whereas other partners prefer a more general plan.

A factor that was found important as well could be called “urgency to go abroad”. Is it a real business interest? A second factor is the capability to go international. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

During the operations phase, technical problems emerged to establish collaboration by application sharing (Portugal). A use case was skipped because of a partner leaving the consortium. As a consequence, new work arrangements were needed. As a general remark, transfer requires good understanding and awareness of what actually has been accomplished and how. 8.5.3 Collaboration bottlenecks

The pilot was managed based on a project plan and project management procedures. There were no specific bottlenecks in collaboration. Participation of SMEs to pilots was limited due to financial reasons. 8.5.4 Collaboration support

Collaboration during the phases

Collaboration between the partners was mostly supported by traditional methods of project planning. Other methods and tools included: • • • •

Technical support via email and phone

Documentation exchange on the SAP Research Middleware for Device Integration prototype (MDI) including installation, usage, configuration etc. Set-up service level agreements to ensure reliable technical support

Software development & licensing agreement as a base for a trusted environment, where no consortium agreement was in place

Collaboration tools

In order to ensure a systematic and regular collaboration between the Living Labs and the connected SMEs, collaboration tools were used as listed below:

•

• • • •

Conferencing tools, such as regular phone conferences on a weekly basis, as well as using webcam & audio. LinkedIn closed group

Use of internal APOLLON portal (myBBT) to share documents and to upload minutes

Remote LL tour with the help of webcam and SAPconnect (incl. web sharing & conference calls) SAPmats (download container tool for "large file" sharing)

Actually for the internal pilot collaboration the most important methods and tools are the regular conference calls to synchronize between each other on a weekly basis and – in a very limited way - the myBBT portal to store and archive documents, minutes and notes. For external communication - not just to within Apollon but also to any other interested parties – it was established webcam tours to systematically disseminate our achievements. LinkedIn did not fulfil the ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

requirements as a collaboration platform as it was found more relevant for contacting and personal networking. B2B specific needs are absent or insufficiently developed for the requirements necessary for our collaboration infrastructure. Simple instruments such as on site visits were found to increase the common understanding of skills, technology possibilities etc. Contractual forms of collaboration, for which templates have been developed, were found useful as well. 8.5.5 Lessons learned and collaboration guidelines

In order to realize the participation of SMEs to pilots, financial support for SMEs will be necessary, especially those targeting cross border activities. Based on the experiences gained during the realization of the use cases it became clear relatively early that it is very helpful to put a collaboration environment in place which facilitates the execution of these cross border activities. Therefore it was put together a precise work plan for the second half of the experimentation with the goal to finally provide a marketplace for SMEs which either provide or seek services. These services may include technology (hardware as well as software), consulting services or "open" services in the way of any kind of collaboration (best practices exchange) via the collaboration platform. In the beginning the cross border activities were mainly focusing on the setup and realization of the use cases Energy Monitoring and Asset Viewing. The cross border activities always followed the same pattern meaning that each use case had its own life cycle where different cross border activities were relevant for a certain phase of the use case realization.

Based on the experiences that were gained during the realization of the use cases it became relatively early clear that it is very helpful to put a collaboration environment in place which facilitates the execution of these cross border activities.

The capacity for partners to cooperate on a regular basis, following Living Lab methodologies, involving all partners in the co-creation and co-implementation of the use cases was a clear success and strong point for the project.

Through the establishment of cross-border business partnerships (B2B), using the APOLLON eManufacturing Living Lab approach, the collaboration accelerated the process of innovation and dissemination of new products / services and the exchange of knowledge. That is specifically proven by the fact that the second use case went live faster due to experiences already built up at YDreams (learning curve). Different participating entities brought different contributions and had different objectives as it can be seen schematically in Figure 8-2.

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Figure 8-2 - Collaboration approach showing the participating entities and interests (Source: D4.4)

This collaborative approach speeded up the establishment of B2B partnerships, thus contributing to the dissemination of new SME solutions and within a broader market. Also, the co-creation of solutions and the collaboration allowed the widespread adoption of best practices.

The Living Lab methodologies are based on an intensive collaboration between partners to enable the co-creation of services and products. This was already proven during the work on the use cases by showing a number of advantages such as an effective way to establish trust between SMEs which is essential in B2B relationships and usually not easy to attain: e.g. you could rely on the local Living Lab having the knowledge of and contacts to reliable local partners, having checked them before inviting them into a new business relation. It also supports continuous innovation driven by users which is in the best interest of the collaborative SMEs.

For the project time being - and beyond â&#x20AC;&#x201C; it is necessary to distinguish between two kinds of cross border activities. The ones that have to do with the "build up" of a domain specific Living Lab network - therefore the interactions between the different Living Labs and the interactions between the Living Labs and SMEs to identify measures, methods and best practices that then help to trigger and run the "other" cross border activities that are in focus of APOLLON which are the cross border interactions between the SMEs as such.

It is believed that the Living Lab network that has been built in this pilot has achieved a high level of SME business suppor. Proof points are the facts that both the stakeholders from Germany as well as from Portugal have the same understanding how a Living Lab network should appear as an instrumental network. As stated above, a common list of requirements was put together which will now be transformed into an internet presence which should work as a marketplace and collaboration platform at the same time. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8.6 eParticipation: a common service integration framework 8.6.1 Pilot context The eParticipation pilot was set up to test how integrated eMedia technologies can encourage eParticipation and to investigate the advantages, best practices and limitations of cross-border activities within the Living Lab network. The pilot was designed to cluster three running local Living Lab projects in three countries, in which social media are being used to stimulate and facilitate the participation of citizens: 1. Issy-les-Moulineaux experiment – The Digital Fort Use Case (France); 2. Issy- les-Moulineaux experiment – Mueseum of Playing Cards Use Case (France); 3. Antwerp Museum of Modern Art Use Case (Belgium); 4. Manchester Art Gallery use case (UK).

In this pilot one specific technology and related service within each Living Lab was selected (3D technologies from French SMEs Navidis and Virdual, social media and community reporters programs from the UK NGO People’s Voice Media, context aware mobile application from the Belgian start-up AirGraffiti now named MuseUS), with the objective to adapt and integrate them with each other.

Main goal of the experiments is cross-border technology and knowledge transfer using a living lab approach for involving the users into eParticipation within the field of cultural and media innovation, using 3D eMedia technologies, context aware technologies and citizen media technologies. In each experiment at least two crossborder technologies were combined. One SME (Virdual) participated in two experiments; another one (Airgraffiti) participated in three experiments. An average 30 participants were directly involved in each experiment evaluation activity. In later activities – focus groups, remote usage, training sessions, a great number of users participated. 8.6.2 Collaboration issues

For all experiments the main collaboration steps were the following (See D5.5 for details):

1) The local living lab orchestrates the construction of the pilot with local SMEs and stakeholders 2) The cross-border SMEs express their needs and objectives for the expereiment

3) The local living lab organizes co-design sessions with local stakeholders and SMEs trying to match the scenario to the cross-border SMEs needs

4) The cross-border living lab monitors the process to make sure the scenario matches the SMEs goals but doesn’t interfere with the unless there is a need to moderate a debate or harmonize the objectives of the different stakeholders and SMEs 5) The cross-border SME visits the local living lab for a co-design session in which the scenario fo the experiment is finalized ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

6) The local living lab is in charge of coordinating the operational phase of the experiment

7) The cross border SME joins the local living lab for the kickoff of the experiment 8) The local living lab is in charge of collecting and analyzing data from the pilot 8.6.3 Collaboration bottlenecks

Creating the network (connect) e.g. setting up the pilot

During the planning of experiment some problems occurred for Manchester Central Library experiment. The planned experiment didn’t take a place, mainly because of the technology issues - the processes for accessing 3D model data was problematic and slow, which caused delays in starting the experiment. There were also some construction works in the Manchester Library and thus the access to the building was forbidden for a long time and delayed the implementation of the experiment.

Different goals and expectations of participating partners resulted also in some difficulties in setting up the experiments. There was the case that one SME (Virdual) didn’t want to engage in further experiments involving the integration Real And More 3D technology in the Manchester experiment or in the Issy museum of Playing cards experiment without first clarifying the business model for their service. The main reason was a divergence in the goals of two partners (Virdual and IBBT) mainly because of different approaches in searching the opportunities for exploring the potential business models (revenue sharing model with museums). Also there was the case to replace one of the partners during the experiment planning and execution: local partners in Issy didn’t want to work with a solution that was not tested (Airgraffiti) and replaced it with local partner Mobexplore As the technologies were similar, there was no need to change the experiment scenario. . A similar issue occurred in the Manchester pilot, but the local living lab finally convinced the Museum to test Museus even if the technology was still in beta phase. The main issue at the beginning of the network creation was that partners didn’t have a complete knowledge of each other expectations and skills. These were progressively defined during the process of co-designing the scenario for the pilot.

Given the different profiles of SMEs partners, the harmonization of partner’s objectives was a challenge needed to be solved at the beginning of the project. SMEs like Virdual and Navidis expected to find business opportunities through Apollon; NGOs like People Voice Media expected an international validation of their activity; Startups like Air Graffiti and the supporting partner Mobexplore wanted to get user traction and visibility through Apollon.

The way in which all partners’ objectives were harmonized was through the process of co-designing the scenarios for each experiment in a way that the goals of each partner were addressed if not completely matched. The process of harmonizing these goals involved some level of compromise for each partner. Planning the network (plan, engage) ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The co-design of the pilot was one of the most labor-intensive phases of the project and involved various iterations that led to the final scenario. The main challenges were the harmonization of partnerâ&#x20AC;&#x2122;s objectives and the integration of SMEs partnersâ&#x20AC;&#x2122; technologies with no budget directly allocated to software development.

Match-making between SMEs and Living Labs is a fundamental step in determining the success of collaboration between Living Lab and SMEs. When the Living Lab ecosystem is not adapted to the SMEs, opportunities are lost. For example, for SMEs as Virdual specialized in the domain of cross-media and Interactive Television, one of the main regrets for Apollon is the fact of not having been introduced to a network of Living Lab with experts in this domain.

In the same way, when the SME solution is not flexible enough it can be hard to integrate it in a Living Lab ecosystem. For this reason, an agile approach (prototype, test, iterate) should be encouraged when working with Living Lab. Startups that can easily pivot if they found unforeseen opportunities benefit from cross-border pilots more than SMEs with a closed solution. On the other hand, the risk of working with a startup which product is under development is to be delayed on the initial schedule. In this process it is also very important to engage the stakeholders into the beginning of experiment planning to be aware of the overall process, application to be used and to enable the engagement of the users in efficient and appropriate way. Operating the network (support)

One of the main challenges for the cross-border was that the travel budget and the development budget for SMEs were very limited. Travel and accommodation costs to enable SMEs to visit potential partners and scenarios in foreign markets will need to be resourced if cross-border Living Labs are to continue to operate after APOLLON. In the same way, not having a budget for developing specific ad-hoc solutions that would have facilitated the integration of two or more technologies was a big constraint for the pilot. Future projects will need to consider this when defining the budget for cross-border pilots involving technology integration.

In the cross-border experiments the language may occur as one of the barriers. The partners and co-partners involved in the all experiment spoke English well, but this may not always be the case in cross-border experiments. Getting access to translation resources can be a challenge for future projects. Translation resources that Living Labs can access (either via support from ENoLL, by reserving budgets or pooling local resources) would need to be made available to support future crossborder experiments. One of the challenges is also how to transform the solutions in experiments and pilots to the marketable services that can be sold. Some insights could be achieved from cross-border experiments that enable gathering of information from foreign markets. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8.6.4 Collaboration support Low cost and / or free web and internet based collaboration tools have helped a lot in the set up and running of the experiments, for example: • • • • • •

E-mail for day to day communication

Dropbox (http://www.dropbox.com) for sharing files without having to email files back and forth. Skype (http://www.skype.com) for video and audio calls.

Google Docs (http://docs.google.com) for collaborative document editing. Vimeo (http://www.vimeo.com) for video sharing.

Delicious (http://www.delicious.com) and Pinboard (http://pinboard.in) for sharing bookmarks.

Though these tools aided the running of the experiment, the use of these tools was taken on as the experiment developed. In future, it would be useful to agree on a range of collaboration tools before the experiment begins so that all participants know what tools to use and what for (e.g. Dropbox to share files). No web-based available project management / 'to-do' list tool was set up for use by the experiment. Though actions were not missed, it usually meant relying on email and individuals project management tools to ensure work was done. In future, it would be useful for the Living Lab and SME to agree on a project management tool to use (such as Basecamp http://basecamphq.com/) before the experiment starts.

There has been some difficulty in using the above tools with some partners (e.g. Manchester Galleries staff,) as their corporate IT infrastructure was very locked down and is not flexible enough to allow staff to set up and use useful tools, such as Dropbox, without clearance by senior managers and IT policy officers. This has caused some slowdowns in working with those staff during the experiments as they were not able to directly access resources that were being freely shared between the Living Lab (MDDA) and the SME (IBBT). The next table presents the collaboration support that has been used within the eParticipation and Media pilot experiments. Phases

Connect (inception)

Planning, developing

Operating (running)

No business model defined at the beginning Central planning and coordination of all the pilots Copyright issues were not

The expectations and goals of all the partners needed to be harmonized Living Lab manager role Liaising with localstakeholders and coordinating the overall

Central planning and coordination of all the pilots From local to global living lab operation

Levels / aspects Strategic aspects of collaboration

ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Operational aspects of collaboration

solved at the beginning

Face to face meetings of IT and service providers and other stakeholders Email (day to day communication) Dropbox (file sharing) Skype (video and phone calls) Google Docs (collaborative documents creation)

setup of the experiment

Workshops Training sessions Testing sessions Brainstorming Guidance by images Guidance by scenarios Ideas Wall posting Categorization of ideas Evaluation of ideas Mediation Discussions Focus groups Email (day to day communicaton) Dropbox (file sharing) Skype (video and phone calls) Google Docs (collaborative documents creation)

Table 8-5: Collaboration methods and tools within eParticipation and Media

Interviews Semi structured interviews (audio recorded) Direct User Observations One to one interviews Web analytics Focus groups Blogs Twitter Email (day to day communicaton) Dropbox (file sharing) Skype (video and phone calls) Google Docs (collaborative documents creation) Vimeo (video) Delicious and Pinboard (bookmarks sharing)

8.6.5 Lessons learned and collaboration guidelines All partners could benefit from cross-border collaboration to improve their technology and better define their solutions. The partners, participating in the cross-border collaboration built up the wider European ecosystem, enabling them further involvement into the new European projects.

SMEs working with Living Labs should be clear what evaluation research they want to get out of the experiment. Even if the product / idea being tested is quite focused (such as an iPhone app), the reason for the carrying out the experiment should be clearly defined before the work required to set up the experiment proceeds. What one or two things is the SME looking to find out by carrying out the experiment? Clarifying this would help to produce much more focused user testing sessions and identify the most pertinent stakeholders to help with the process.

Living Labs willing to realize cross-border activities involving multiple partners will need to take into account their different goals. One solution to reduce the complexity of managing this issue could be to start from one SME goals and try to find partners that have compatible expectations. The importance of harmonization of different partnersâ&#x20AC;&#x2122; objectives, especially in the case of working with partners with different profiles (NGOs, SMEs, Startups) must not be underestimated as this is a baseline for the fruitful collaboration of the consortium. The co-design phase took the most of effort in all the experiments (namely from the definition of the scenario to identification and involvement of the relevant ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

stakeholders. The early involvement of key stakeholders into the experiment planning is very important.

From the perspective of overall coherence of the pilot and each experiment there is a need for the supervising role of one partner, having the task of precise project management of all partners and activities with appropriate (possibly web based) tool .

One of the lessons learned is also that the Living Lab should not step back after the SME and local partners and participants have been introduced and scenario identified, but work with all the participants to ensure that the experiment is carried out successfully, also supporting all the communication between the SME and other participants, to make sure that all involved are aware of their roles and responsibilities during the experiment. Pilot was mostly focused to cross-border integration of different technologies. Lessons learned was that cross-border testing is more profitable for light technologies, using widespread technologies (e.g. iOS, Google maps) with a prototype and start up approach, which can be more quickly adapted to the different geographical and cultural settings.

Using new technologies and media attracted especially younger population and resulted in overall positive feedback. However this might be an obstacle for older population and for those who do not have available appropriate equipment for application and service usage. Living Lab should consider these possible obstacles and ensure the needed equipment for the all users, participating in the experiment and pilot. Also the need for training should be considered.

The living lab approach was proved as an appropriate environment for testing and further development of applications in local and cross-border environment, incorporating the cultural and other market differences and needs; with strong user and key stake holder involvement. Some of the SMEs developed new business and market opportunities. The approach also enabled some insight for identification and development of appropriate business models. The recommendation is also to set up the centralized â&#x20AC;&#x153;contact of customer relationship managementâ&#x20AC;? system in Living Lab organization to keep details of contacts that are willing to participate as testers, businesses, business partners, organizations etc â&#x20AC;Ś IPRs and related licenses (copy rights creative commons) need to be defined at the beginning of the project to enable partners to understand, what are the expected inputs and outputs of the projects. The Living Labs approach and open innovation methodology should support hybrid models (e.g. creative commons) that allow the copyright holder to share some part of the knowledge generated through and innovation project with a wider community. In the cross-border environment language may occur as the barrier. Translations need to be done through involvement of native speakers. ICT PSP Project Reporting

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

ENoLL should provide a collaborative platform in which Living Labs and SMEs could meet, match their needs and skills and exchange services.

One of the problems was that there was no additional budget that could be allocated to new partners being added to the experiments or SMEs that needed to provide additional ad hoc development to adapt to the scenario or to make sure that two applications could be integrated effectively. Future cross-border pilots involving the integration of two technologies will have to consider this issue. Four solutions can be proposed to deal with this issue in future projects: • •

• •

Keep a budget for additional partners that need to join the consortium of for extra development costs that need to be covered;

Encourage the participations of SMEs that can adapt quickly to shifts in the scenario and have developed or are willing to develop solutions (such as APIs) that can facilitate the integration with third party applications; Sufficient budget planning for traveling of partners.

Sufficient budget planning for translation of cross-border materials.

Future projects will need to make sure to attribute a sufficient time to the matchmaking phase before beginning the project since this is a fundamental step for making sure that Living Labs and SMEs expectation and goals can be fulfilled.

8.7 Cross-pilot analysis, guidelines and conclusions 8.7.1 Cross-pilots analysis

The four cases presented here demonstrate that in each of the pilot environments the situational context of living labs collaboration was different. On the other hand we see some similarities. The four pilots should be seen as cases which we can learn from in making general conclusions for next activities. In Table 8-5 we summarize the main situational characteristics, The homecare and independent living pilot is structured as a set of project-like experiments in which a technology solution is transferred from one country to another. The pilot collaboration needs are largely determined by the need to set up a similar local ecosystem and engaging local stakeholders, and the need to adapt the solution to local context. For this no ready to use methodologies exist apart from usual approaches such as requirements definition and normal standards of project management and stakeholder involvement. and actually the approach was developed within the pilot. Critical is sound project definition and management and building good understanding and communication between the “sending” and “receiving” living lab teams. Critical is also the existence of a clear business case and business opportunity for all partners. Also it is highly important to be able to demonstrate technologies and systems for creating a good understanding of the solutions. ICT PSP Project Reporting

100

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The energy efficiency pilot results into forms of cross-border interaction an collaboration focusing mostly on dissemination of knowledge and experiences gathered in the experiments. The cross-border collaboration aspect is rather weak and actually SMES involved did not have much interest to test their technologies abroad. The pilots is using various methods such as user behavior transformation approaches, the contextualization of such approaches might constitute a benefit for cross-border collaboration. However the original purpose of establishing a benchmark framework of use within a cross border setting of comparable experiments was not realized. Within a setting of more or less independent local experiments on smart metering, for truly exploiting the opportunities of international collaboration this pilot needs an agreed project definition and project plan reflecting the different commitments and business cases involved.

The eManufacturing pilot was strictly organised as a project from the advance. This pilot setting can be considered as more simple compared to the other pilots: less partners, clear problem definition and timeframes, clear objectives and clear expectations regarding results of the use case experiments. The setting aimed to create, and explore the benefits, of B2B partnerships in eManufacturing solutions. As a conclusion a common technology platform (and a common project with relatively high commitment level) offers a good basis for technology cooperation among complementary partners. This pilot however provides less insight in the way collaboration was structured, motivations for collaboration, business benefits expected and achieved etc. The eParticipation pilot was also structured as a set of projects (experiments), where technologies that were developed elsewhere were integrated into a solution using a living lab approach. The pilot demonstrates some bottlenecks that hinder cross-border collaboration, such as differences in goals and expectations as well as differences in business cases. Also language plays a role. The process of scenario codesign helped to harmonize partnersâ&#x20AC;&#x2122; objectives and to facilitate the integration of technologies facilitated. Also the use of application development frameworks and project management methods and tools facilitated collaboration. The role of living labs in the collaboration setting seems to be very important in order to prepare and carry out the experiment successfully. This also requires project management skills and competencies. Homecare and independent living

Energy efficiency

eManufacturing

eParticipation and Media

Situational characteristics determining collaboration

Different ecosystems at sending and receiving end

Different Smart Meter experiments in several countries, interrelation mostly lacking

Integration of technologies from elsewhere into applications for sue in another context

Main collaboration issues

How to jointly resolve technical and legal issues

How to benefit from experiment outcomes elsewhere

Available middleware platform offered by SAP Pilot was organised as a project and clear use cases from the beginning

ICT PSP Project Reporting

101

How to support B2B collaboration on testing of technologies

Creating a strong collaboration between living labs, and

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines How to agree on project and experiment definition How living labs act as â&#x20AC;&#x153;hubâ&#x20AC;? for SMEs

How to create a common benchmark for experiments and use it to improve technologies

How to create a marketplace for services

between living labs and SMEs, NGOs and start ups

Lack of cross-border collaboration

Difficulty for SMEs to participate without financial resources

Factors determining collaboration bottlenecks

Quality of project plan and project management

Financial resources of SMEs

Collaboration methods and tools successfully used

Project planning and management Value Analysis Communication tools

Quality of project planning and management Business interests of local partners Lack of involvement of SMEs and lack of interest for internationalisation

Technical problems of integration of technologies Role of the living lab to coordinate the experiment Divergence of partner goals, skills and expectations

Need for approaches to raise the engagement level of partners involved Need to clarify in advance the business case of cross border collaboration for this pilot and for all partners Focus on methods that can be sued in different contexts e.g. behavioural change

Importance of a clear project plan and project management

Collaboration bottlenecks

Main lesson learned

Creating the receiving ecosystem

Clear business case (win win) for all partners, including business opportunity after project end Roadmaps of partners should be aligned Importance of value analysis for mapping partner objectives Importance of sound project management

Dissemination and exchange approaches e.g. Roadshows

Table 8-6: Cross-pilot analysis of collaboration

Project planning and management Communication tools

Lack of expertise in Living Labs Inflexibility of SMEs solutions Financial constraints of SMEs

Low cost web-based communication tools Clear definition of experimentation outcomes of the experiment by SMEs Agile approaches are necessary to succeed in integrating a technology into another application Matchmaking between SMEs and Living Labs is fundamental in determining the success of collaboration

8.7.2 Main collaboration guidelines Ensure collaboration agreement

It is one of the characteristics of the APOLLON project that before the pilots start the project proposal had to be approved, without a clear commitment of SMEs and living labs to agreed results. Actually this means the connect (and partly also the plan) phase is taken for granted. However during the connect phase important agreement are to be made e.g. regarding business model, IPR, business proposition, and contractual agreements. Mostly this has been missed in APOLLON and his should be considered as the key reason of the sometimes lacking commitment. ICT PSP Project Reporting

102

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Define clear roles and responsibilities of living labs and SMEs and other partners

Several pilots evaluations conclude that the roles definition, in particular as it comes to the role of Living Labs, is highly important. In case there is a transfer situation such as in the Homecare and independent living pilot and in the eParticipation pilot, the receiving living lab should assume the coordinating role. To ensure that this role can be fulfilled, the living lab should have the necessary competencies, expertise and skills. A lesson learned in the eParticipation pilot is that living labs should not step back after SMEs and local partners have been introduced and the scenario defined but work with all participants to realize the experiment. In case of the energy efficiency pilot, where the objective was to create a common benchmark, the Living Labs should first develop a detailed and agreed plan and should ensure the collaboration of all partners including SMEs. Ensure an agreed common business case before starting

Most of the pilots experienced difficulties in engaging the partners and ensuring commitment. As a rule objectives, results to be achieved, time frames, needs and expectations of partners need to be clearly defined and aligned to the project goals before the pilot starts. A win-win for all parties involved should be negotiated before the actual start. One way to realize this is to ensure that the pilot is part of the roadmap of SME’s and other parties involved. Also, the pilot should target clear business opportunities that can be gained after project’s end. Ensure adequate project planning and project management

Pilots and experiments within the pilots after all are projects in their own. Sound project definition, project management and the use of project management tools is a precondition for success. This is assumed to be well-known fact but actually it has been a problem in several pilots. There is a need for project management methods and tools that reflect the setting of cross-border partners and to be flexible to accommodate the joining or leaving partners. Use adequate collaborative workspaces and communication tools

Most pilots are using a combination of usual communication tools such as teleconferences, skype and other tools. Use of shared workspaces is limited even where it seems that it could have contributed to better project planning and management.

Make sure that technologies to be tested or used in other contexts are compatible

Several pilots have been coping with the problem of technologies that have been developed in one context and were not compatible in another environment. In particular the homecare and independent living pilot, the energy efficiency pilot and the eParticipation pilot were coping with these problems. This “localisation” issue deserves more attention in terms of pilot preparation, technology analysis, testing procedures, local situation analysis. Also legal and organisational issues may hinder the application of a technology. ICT PSP Project Reporting

103

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

9. Foundational Methodologies and Frameworks This section addresses overarching methodology issues in cross border networking of living labs. Here we point to the general, “foundational” methodologies and frameworks that are useful to guide the strategy for creation of living labs networks for open and user driven innovation. • • • • • •

Research framework for designing and evaluating living labs networks Action research framework for implementation of the living lab network Cross border living lab network pilot development and execution Socio-technical change, actor network theory and related frameworks Living lab methodologies for open and user driven innovation Creating and operating virtual organizations

9.1 Research framework for designing and evaluating experiments in Living Labs networks Issue: A main objective of Apollon is to experiment and demonstrate the cross border living labs networks in four piloting environments, addressing four different challenges of interoperability and harmonization. The general pilot deployment approach consists of the following steps: 1. Preparation of experiment, 2. Set-up of the experiments, 3. Cross-border piloting, 4. Evaluation and learning. A systematic approach is needed for to support the setting up, operation and evaluation of these experiments. Additionally, the framework should offer guidance to jointly develop and validate the methodology. Solution: A simple research framework has been developed which is based on design science principles. The framework is offered in the form of a matrix of different types of outputs and research activities. Outputs comprise the cross border living labs network, as well as the underlying constructs, models, methods that are developed – in a learning process- to create the network. Research activities comprise four types: build, evaluate, theorize, justify. Besides offering guidance to pilot experimentation, this framework also acts as a guidance to build, evaluate and understand the methodologies (methods, tools, guidelines) which support the creation and operation of cross border networking of living labs which can be recommended for future initiatives.

Research activities: design

ICT PSP Project Reporting

104

Research activities: understanding

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Constructs (concepts) Research Outputs

Build

Evaluate

Theorize

Justify

Models (living lab network scenarios) Methods (methodologies) Instantiations (living lab network pilot)

Both the methodology of creating and supporting cross border networks, and the cross border networks themselves (in pilots) are outputs of the research. The research framework consists of a set of questions that guide the harmonized creation, implementation and evaluation of the cross-border living labs network pilot as well as the methodologies.

For particular aspects of the framework we have developed specific methodologies: â&#x20AC;˘

â&#x20AC;˘

Evaluation of the living lab pilots. Pilotâ&#x20AC;&#x2122;s evaluation is based on identifying Key Performance Indicators (KPIs) and focuses on evaluating the value added of cross-border living labs networking. Methodology validation. Methods and tools or guidelines to support crossborder networks are partly developed within the methodology group and partly within the pilots. Within the pilots, a process of methodology needs finding, introduction, adoption, use and evaluation is taking place. This process is monitored in three-monthly cycles.

Relevance: The research framework structures the creation, evaluation and understanding of cross border living lab networks in the vertical pilots and provides a way of comparing the different pilots. At the same time it structures the methodology development process in the vertical pilots. The research framework is a dual framework which connects the complementary interests of researchers (interested in methodology development and validation) and pilot experimenters (interested in building the pilot and evaluating its success).

Evaluation: Some aspects of this research framework have been used, in particular in the Homecare and Assisted Living, and in the Energy Efficiency pilots, to guide the pilot design and evaluation. The evaluation aspects of the framework are built in within the general deployment approach of the pilot experimentation. ICT PSP Project Reporting

105

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Sources: Design science: March and Smith (1995), Hevner a.o. (2004). See also the web page on “Design Research in Information Systems”.

Remarks: Please note that this presentation differs from the presentation in the D1.2 deliverable and provides a more coherent approach which sticks more to the original scientific literature. It also should be noticed that the design science approach and the resulting research framework is related to Action Research (see below) and comprises process steps such as awareness of the problem, suggestion, development, evaluation, and learning.

9.2 Action research framework for implementation of the living lab network Issue: Creating and eventually operating the living labs network needs practical implementation of methods, systems, applications, collaboration processes, which is a process of social change. Action research (AR) is a form of applied research where the researcher becomes part of the phenomenon studied and works with the problem owner (“problem” is understood in a general way where there is a need for change). AR is an interactive, collaborative process between research and practice which generates a thorough, joint understanding of the situation at hand. The aim of AR is to develop solutions to practical problems; it is of value for the people with whom the researcher is working while at the same time developing theoretical knowledge of value to the research community. The issue is how to apply this approach to implement new forms of cross border living labs cooperation.

Solution: We consider the process of creating and implementing the living labs network as a change process. The AR approach starts from identifying the realworld problem (setting up the living lab collaboration). The roles of problem owner (Living labs, SMEs) and researcher (Apollon team) are agreed through negotiation. Solutions are jointly developed and agreed, implemented and evaluated, which can take a number of cycles. The process ends in lessons learned. Several of these cycles follow until final problem solving.

Within Apollon a collaborationship is arranged between the project researchers and the beneficiaries who are living labs and SMEs. Researchers, Living Labs and SMEs have established a common agenda and pursue common goals. Actually we have two interacting and interrelating cycles: the cycle of methodology development and the cycle of pilots’ implementation. Action research benefits from a diverse set of methods and tools, among which the following are the most important. • • •

Organizing the innovation as cycles of problem identification, solution finding, prototyping, testing and evaluation. Visualization techniques and process approaches e.g. graphical approaches as proposed by Peter Checkland in his soft systems methodology.

Process consulting methods, as “clinical” form of action research, put the client central in such a way that the consultant works with the client (Edgar Schein).

ICT PSP Project Reporting

106

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Within Apollon the client is driver of the innovation process. Process consultation aims to educate the client through early interventions and involves the helper consultant in the client’s inquiry process, driven by client needs.

Relevance: AR is relevant for Apollon as it provides an interactive, learning based process approach to the setting up and operation of cross-border networks of living labs. It ensures an explicit recognition of the roles of researchers and problem owners.

Evaluation: Elements of AR have been applied as part of the project structuring and implementation of cycles of methodology introduction and evaluation. However it has not been applied in a conscious manner. The aspect of pilot evaluation is an explicit part of the vertical pilot. The cycles of methodology evaluation and validation are ongoing and will be concluded with lessons learned. Sources: Baskerville (1999), Checkland and Holwell (1998), Stahlbrost (2010), Schein (1995).

9.3 Cross border Living Lab network Pilot development and implementation

Issue: Within the different piloting environments, cross border living labs networking is demonstrated and investigated. A structured approach is needed to organize and coordinate the piloting and experimentation process.

Solution: The general pilot deployment approach consists of the following steps: 1. Preparation of experiment, 2. Set-up of the experiments, 3. Cross-border piloting, 4. Evaluation and learning. Relevance: Piloting and experimentation is a key methodology within Apollon.

Evaluation: The piloting methdology is developed, adapted, implemented and evaluated within four environments. Sources: Apollon evaluation reports.

9.4 Socio-technical change, actor network theory and related frameworks A number of related frameworks exist that provide theoretical background to the phenomena investigated in Apollon:

•

Actor-Network Theory (ANT) constitutes a theoretical framework useful for understanding sociological phenomena in relation to the use of information systems.

Information systems change explained as socio-technical change: a large body of work exists (Lyytinen and Newman, 2008). The “work system” approach of Alter aims to describe and understand systems change in organisations. Theories related to mutual shaping and sensemaking (Orlikowski, 2000). Mutual shaping and sense making oriented research emphasises the interplay between technology, organisations and behaviours in shaping collaboration processes

ICT PSP Project Reporting

107

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

and adapting and using technologies in organisations. It proposes to view the adaptation, shaping and use of technologies as outcome of social action processes, establishing new collaborative practices. This view allows a better understanding of the processes of adaptation, adoption and change, which also relates to theories of organisational learning.

9.5 Methodologies for networks of living labs

Issue: During the last years substantial work has been carried out on methodologies in the area of living labs for user driven and open innovation. Examples of dedicated methodology work combined with pilots are FP6 projects such as C@R and ECOSPACE. Another example of a “living lab toolbox” is the Nordic project. Some academic work on this matter is also emerging. However from the point of cross border collaboration networks of living labs, no real recommendations or insights are available.

Solution: Lessons that can be learned from the perspective of networked living labs, from existing projects, have been summarized by Apollon D1.1. However, very little is concluded regarding living labs methodologies within networking settings. Living labs networks, especially cross-border, are a relatively new phenomenon. Most networks are dedicated to exchange of information, knowledge and lessons learned. In some cases we see examples of sharing and reusing of software components based on common platforms, and use of common methodologies (C@R and Ecospace as most pronounced examples). Recommended elements of living labs methodologies within a setting of networked living labs are the following. •

•

Establish the boundary conditions for open innovation in networked collaborative innovation. This implies dedicated partnership agreements, business models and IP arrangements (as discussed earlier in this document).

Methods to conduct user driven experimentation and evaluation activities within a networking setting. This implies the need for methods concerning how key living lab activities should be carried out in a cross border setting. Such activities include: Technology demonstration and experience, Lab and Field experimentation, and Longitudinal pilots. Of special interest are methods for interaction between software developers and users within a (cross border) networking setting, as well as tools to create and maintain large, cross-border, user communities for co-creating testing and evaluating solutions. Using common software platforms and web 2.0 tools for cooperation on applications development, testing and evaluation and on managing large scale user communities.

9.6 Creating and operating collaborative and networked organizations

More and more, people and organizations are interacting, collaborating and innovating in networked organizational forms. Such networks can take different shapes, including virtual organizations and professional communities. A general ICT PSP Project Reporting

108

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

term is “collaborative networked organizations” (Camarinha-Matos a.o. 2008). In developing methods and tools for supporting networks of collaborating living labs and the wider domain networks within they act, we can learn from the methods and tools that have been developed to support the creation, management and operation of collaborative networked organizations (CNO). Examples are: •

•

Structuring the process of creating the living labs network: CNO literature describes the Virtual Organization creation process as a sequence of activities including collaboration opportunity characterization, rough planning of the Virtual Organization, partners search and selection, negotiation, detailed virtual organization planning, contracting and launching of the virtual organization.

Models, processes and tools to support the steps in creating living labs networks: CNO literature has developed detailed models and templates to support the steps within the creation process. Examples are partner search tools, contract negotiation wizard, IP management frameworks. Frameworks for management of living labs networks: CNO literature has proposed detailed management frameworks related to collaborative networked organizations.

For Apollon methodology development these methods and tools are relevant at the conceptual and structuring level. Besides, CNO literature offers a comprehensive box of concepts, methods, tools and processes that can be used as background for developing comparable methods and tools for living labs networks.

ICT PSP Project Reporting

109

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

10. Knowledge Center 10.1 Background A number of methods, tools and guidelines as proposed and developed within the APOLLON project have now been made available for a wide audience through the Knowledge Center (http://knowledgecenter.openlivinglabs.eu).

The Living Lab Knowledge Centre was initially set up by the Amsterdam Living Lab (www.amsterdamlivinglab.nl), which started in 2008 with the goal to help companies to test new products in a real user environment. The Knowledge Centre went on line under impulse of Novay by mid 2010. Further development of the portal and its functionalities is co-financed through APOLLON. From its launch, a strong connection existed towards Europe with other Living Lab initiatives. By end 2010, APOLLON therefore decided to host the living Lab Knowledge Center as part of the openlivinglabs.eu portal, the official site of ENoLL iVZW, the European Network of Living Labs. This, way, it is expected that the Knowledge Centre will remain firmly embedded in the Living Lab Community, and grow as user-based repository of best practices and methodologies. The Knowledge Center portal consists of several parts: •

• • •

Support: This part provides help in setting up and running a living lab project or network. Essentially it is here that APOLLON results in terms of methods, tools, guidelines have been made available. This part is structured according to the known phases Connect, Plan and Engage, Support and Govern, and Manage and Track. Learn: this part provides access to Living Lab methods, techniques, tools, sensors based on a search engine.

Find: this part allows to find living labs, projects and partners according to specifications.

Best practices: This part contains a number of good practices of living labs management which are expected to be useful for new initiatives. Topics for best practices are, e.g., management of intellectual property rights (IPR), licensing and other.

10.2 APOLLON contributions

The contribution of the APOLLON project to the Knowledge Center consists of the collection of methods, tools, guidelines and practices brought together in this Deliverable.

ICT PSP Project Reporting

110

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Annex 1: References and Other Sources 1. Literature • • •

• • • • • • • • • • •

• • •

Allee, V. (2008): Value Network Analysis and value conversion of tangible and intangible assets. Journal of Intellectual Capital Volume 9, No 1, pp. 5-24 APOLLON project (www.apollon-pilots.eu): Project deliverables.

Camarinha Matos, L. et al. (2005): Towards a Framework for Creation of Dynamic Virtual Organizations. In: Collaborative Networks and their Breeding Environments, PRO-VE’05, Springer. Camarinha-Matos, L., H. Afsarmanesh (2006): A Modeling framework for Collaborative Networked Organizations. Proceedings of PRO-VE’06, Springer.

Camarinha-Matos, L., A. I. Oliveira (2007): Contract Negotiation Wizard for VO Creation. In: Cunha P.F. et al., Digital Enterprise Technology. Springer. Camarinha-Matos et al. (Eds.) (2008): Methods and Tools for Collaborative Networked Organizations. Springer.

Chesbrough (2006): Open Business Models. Harvard Business School Press. DG Enterprise and Industry (2008): Supporting the internationalisatioin of SMEs. Good practice selection. DG Enterprise and Industry (2010: Internationalisation of European SMEs

Faber and De Vos (2008): Creating Successful ICT Services. Telematica Instituut. Gusmeroli, Ratti and Serina (2007)

Hevner, A.R. et al. (2004): Design Science in Information Systems Research. MIS Quarterly Vol. 28, No. 1, March 2004.

Löh, H., H. Schaffers (2008): ECOSPACE D5.1B Ecospace Living Lab Experimentation and Evaluation Methodology.

Löh, H., H. Schaffers, K. Kristensen, S. Budweg (2009): From Theory to Practice. Making Product and Service Innovation Happening in CWE-related Living Labs. White Paper, draft. March, S.T., G.F. Smith (1995): Design and Natural Science Research on Information technology. In: Decision Support Systems 15, pp 251-266.

Osterwalder, A., Y. Pigneur, C.L. Tucci (20065): Clarifying Business Models: Origins, Present and Futures of the Concept. Communications of AIS, Vol. 15.

Peltoniemi, M., E. Vuori (2004): Business Ecosystem as the New Approach to Complex Adaptive Business Environments. Frontiers of E-Business Research 2004, PP 267-281.

ICT PSP Project Reporting

111

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • • •

Vraalsen, F., T. Mahler (2005): Assessing Enterprise Risk Level: The CORAS Approach.

Branscombe, L., P.E. Auerswald (2001): Taking technical risks. How innovators, executives and investors manage high-tech risks. MIT Press. Ratti, R. et al. (2006): Specification of VO Creation Tools. ECOLEAD Project deliverable D23.2.

Schaffers, H. García Guzmán, J., Navarro, M., Merz, C. (Eds.) (2010): Living Labs for Rural Development. Tragsa, Madrid. Vallat, J. (2009): Intellectual property and legal issues in open innovation in services. Report published by DG Information Society.

2. Internet sources

http://en.wikipedia.org/wiki/Open_business.

http://ec.europa.eu/enterprise/policies/sme/documents/internationalisation/.

http://www.enterprise-europe-network.ec.europa.eu/about/branches/eg/cairogiza/technology-innovation-centers http://www.enterprise-europe-network.ec.europa.eu/index_en.htm. www.tii.org

http://en.wikipedia.org/wiki/Business_Model_Canvas/

http://www.thinkipstrategy.com/ipthinktank/376/intellectual-property-businessmodels/ http://knowledgecentre.openlivinglabs.eu/

http://en.wikipedia.org/wiki/Collaborative_software http://en.wikipedia.org/wiki/Design_Science/

ICT PSP Project Reporting

112

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Annex 2: Detailed Descriptions of Selected Methods, Tools and Guidelines Method, Tool, Guideline

Contributor

Target group 8

IBBT

Cross-border Living Lab Partner Contract Template

Business Model design for Cross-Border Living Labs Networks

Contacting and Profiling Platform on Knowledge Center

Aalto

Requirements Analysis

IBBT

L, S

Aalto

S, L

4. 5. 6. 7. 8. 9.

Basic Contract Between Test Users and Living Lab Policies and Regulations Database Value Analysis

Decision and Management Support Framework

Project plan development for a Cross-Border Living Labs Network

10. Cross-border Knowledge Sharing

S, L

Setting up and planning cross border living lab network

Aalto

L, S

SAP

L, S, R

Setting up and planning cross border living lab network

IBBT

Aalto

S, L

Aalto

L, S

CDT

AAL, SAP

L,S,R,P

14. Cross-border Application development Framework

UP8

16. Platform for Cross-Border Trading of Services

SAP

11. Observation Data Collection and Focus Groups 12. Collaboration and Communication Tools

13. Dedicated Project Meeting 15. Community Reporting Tool 17. Remote Guided Living Labs Tour Using Webcam and Web 8

Primary use category

UP8

SAP

L,S,R,P

UP8

S, L

SAP

Setting up and planning cross border living lab network Setting up and planning cross border living lab network Setting up and planning cross border living lab network Setting up and planning cross border living lab network

Operation of cross-border living labs networks Operation of cross-border living labs networks Operation of cross-border living labs networks Operation of cross-border living labs networks Operation of cross-border living labs networks Setting up, planning, operation phases Setting up, planning, operation phases

Specific problems or Issues (in this case: WP5) Specific problems or Issues (in this case: WP5) Specific problems or Issues (in this case: WP4) Specific problems or Issues (in this case: WP4)

S = SME, R = Research / Consultant, L = Living Lab, P = Policy makers.

ICT PSP Project Reporting

113

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Conferencing

18. Test Storyline for User Communication

CDT

20. Checklist to prepare for product or service introduction

SAP

19. Method for Designing Use Transformation Processes

CDT

21. Checklist to implement a use case in another environment

SAP

23. Expertise database

SAP

22. Customer Review Questionnaire

ICT PSP Project Reporting

L L

Specific problems or Issues (in this case: WP3) Specific problems or Issues (in this case: WP3) Specific problems or Issues (in this case: WP4) Specific problems or Issues (in this case: WP4) Specific problems or Issues (in this case: WP4)

SAP

Specific problems or Issues (in this case: WP4)

114

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

1. Cross Border Living Lab Partner Contract Template Contributor: Aalto University School of Economics (AAL) 1.1 Problem or requirement addressed by the method Overview This tool provides a template for a contract agreement between the cross border living lab partners. A contract agreement is a document where the project partners formally agree on and commit to carrying out the cross border living lab project. The contract agreement is a legally binding document.

Every project requires formal contract agreements to be made between the partners, verified by the signatures of each party. These contract agreements should be one-on-one, that is, agreed on and signed between two partners. Therefore, multiple contract agreements should be made within one single cross border living lab project. In addition, an overall consortium agreement can also be made, nevertheless, this should not replace the one-on-one agreements as changes, surprises, deviations from plans occur in every project, and an overall consortium agreement often is too general to cover many of such situations. Producing the contract agreements should be on the responsibility of the project manager of the cross border living lab project. As the contract agreement requires elements from the project plan, it is suggested to be made after producing the project plan, however, as early as possible during the Plan and Engage phase of the cross border living lab project. Cross cultural considerations and need for a contract agreement

When preparing the contract agreement in a cross cultural, cross border living lab context, the project manager has to bear in mind that in different national cultural environments such documents as contract agreements, despite their legally binding status, are paid attention to in highly different ways. In some countries contract agreements are taken literally and truly as a legally binding document. In other countries, a contract agreement might be considered as just â&#x20AC;&#x2DC;another piece of paperâ&#x20AC;&#x2122; that has to be prepared, but it is not necessarily considered to be a legally binding document in any way.

For the project manager, a starting point for assessing the way the nationalities involved in the living lab project consider the contract agreement is the cultural value indices (Hofstede). In terms of the contract agreement, especially the Uncertainty Avoidance is helpful. In general, it can be said that in high uncertainty avoidance countries, contract agreements are developed meticulously and followed to the word, and vice versa in low uncertainty avoidance countries.

Another starting point is the cultural dimensions (Hofstede, Trompenaars), and especially the Universalism â&#x20AC;&#x201C; Particularism dimension. In general, it can be said that the more universalist a country is the more contract agreements are paid attention

ICT PSP Project Reporting

115

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

to and considered as legally binding. On the contrary, in particularist countries, business relationships are based on personal relations. Therefore, contractual documents, such as a contract agreement, are paid less attention to and they are not considered to be as legally binding, for example, in situations of conflict, change, and deviations.

Despite such cultural variations, however, the project manager is advised to prepare the contract agreements thoroughly between the partners. This is because in situations of changes, surprises, and in difficult deviations from plans the contract agreement is the only document which enables the parties to take matters into international court, should the situation call for such measures. In this way it still protects the participants in many ways: protects rights, patents, knowledge creation, intellectual property, etc.; it protects, for example, against false lawsuits, and overtly opportunistic behavior etc. Therefore contractual agreements need to be in place between the project partners. Fundamentally, contract agreements are also an important tool for developing trust and open communication between the project partners. 1.2 Description of the Method

Below is a description of a ready-to-use contract template for a cross border living lab project. The project manager is advised to fill in all the relevant parts of the template in order to produce the contract plan. As the contract agreement includes parts from the project plan, that plan is should be first produced by the project manager. CONTRACT AGREEMENT 1. PROJECT partners

a. Name of the partner 1 here

b. Name of the partner 2 here

have agreed the following:

2. BACKGROUND

Project partners agree to take part in â&#x20AC;?PROJECT NAME HEREâ&#x20AC;?. FROM THE PROJECT PLAN, SHORT DESCRIPTION OF PROJECT HERE.

3. OBJECT OF AGREEMENT

The object of this agreement is NATURE OF THE CROSS BORDER LIVING LAB PROJECT HERE (i.e. cross border business ecosystem development, cross border RDI benchmark development, cross border technological platform development or cross border product/service integration development), which has been described below. FROM THE PROJECT PLAN, SHORT DESCRIPTION OF PARTNER RESPONSIBILITIES IN THE COLLABORATION HERE. 4. EXECUTION OF THE COLLABORATION ICT PSP Project Reporting

116

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Between dd.mm.yyyy â&#x20AC;&#x201C; dd.mm.yyyy the partners shall carry out PROJECT NAME HERE, of which the details have been agreed between the partners in dd.mm.yyyy (APPENDIX: PROJECT PLAN). FROM THE PROJECT PLAN, LIST OF COLLABORATING PARTNERS HERE.

FROM THE PROJECT PLAN, LIST OF PROJECT RESPONSIBLE PERSONS HERE.

The partners may use subcontractors and/or substitutes/replacements when necessary. The partners are responsible for the subcontractors, substitutes, and replacements agreeing on the same non-disclosure agreement which is specified in section 7. The collaboration covers the following responsibilities, tasks, and deliverables:

FROM THE PROJECT PLAN, SHORT DESCRIPTION OF PARTNER RESPONSIBILITIES, TASKS AND DELIVERABLES HERE. 5. DEFINITIONS

Project means SHORT DESCRIPTION OF PROJECT WORK HERE agreed upon in this agreement. Outcomes mean patents, inventions, software, knowledge having economic value, documents describing these, and technical documents that the partners produce in this project.

The outcomes of this project do not include such knowledge, patents, inventions or software with economic value that the partners hand out for usage in the project.

Property rights include tangibles as well as patents, inventions, copyrights or other intangibles whether they can be patented or not. Rights of use mean the right to use the outcomes of the project in the own research or business of the partners. Patents and invention means patents and inventions described in the Patent Law and in the Employee Inventions Act. Agreement partner means the signatory of this agreement. 6. PAYMENTS

FROM THE PROJECT PLAN, SPECIFICATION OF PARTNER PAYMENTS TO THE PROJECT HERE.

In default of payments rent per annum shall be paid according to the NAME OF THE RELEVANT LAW/ACT HERE. 7. NON-DISCLOSURE AGREEMENT

This section shall be noted in section 8 in outcome publication.

All data, including the outcomes, in verbal, written, and in electronic form, that one partner releases to another is considered confidential/classified. ICT PSP Project Reporting

117

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Classified corporate and professional knowledge/secrets are confidential both during and after the project. THE NAMES OF THE PARTNERS shall treat all aforementioned data and knowledge as confidential whether or not it has been explicitly marked as such. THE NAMES OF THE PARTNERS declare that they: •

•

do not use data and knowledge they have obtained for any other purpose than the responsibilities specified in this agreement, until X NUMBER of years have passed do not pass on the data and knowledge they have obtained to a third party without a priori written consent from other partners. This has to be obtained each and every time for every intended passing on of the information.

Non-disclosure agreement does not, however, apply to that kind of confidential data and knowledge that the recipient can prove to: • • • • •

having been public or accessible to general public upon signing of the agreement, having become public or accessible to general public after signing of the agreement due to reasons other than those of the recipient.

having been in the possession of the PARTNER NAME HERE at the time of the signing of this agreement,

having gained possession from a third party without non-disclosure agreement, having been developed independently.

8. OUTCOME PUBLISHING

When publishing the outcomes corporate or professional knowledge/secrets cannot be published, neither knowledge that might prevent the patenting of inventions made during the project. To ensure this the partners have the right to examine the outcomes intended for publishing, and demand for the removal of corporate of professional knowledge/secrets. Unless the partners exercise this right within 30 days from obtaining the data/knowledge, permission for publication has been granted. DESCRIPTION OF RESERVING OF RIGHTS PER PARTNER HERE. 9. INTELLECTUAL PROPERTY RIGHTS

Property rights to the outcomes of the project belong to the PARTNER NAMES HERE. 10. RIGHT TO USE THE OUTCOMES

PARTNER NAME receives the right to use the outcomes of the project. This right will be relinquished without any monetary compensation excluding patents, inventions and software, in case of which the compensation shall be reasonable. Right to use will remain in force after the project has been finalized. ICT PSP Project Reporting

118

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

PARTNER NAME shall not pass on the aforementioned right to use to a third party. Despite this, PARTNER NAME retains the right to sell its customers products that it has developed based on the outcomes of the project. 11. PATENTS, INVENTIONS, AND SOFTWARE

Partners shall make sure that any premature publication of an invention does not take place. PARTNER NAME is responsible for all the expenses incurred by patenting or registering. 12. LIABILITIES

PARTNER NAME will carry out the project and the work in it with all the necessary care and professionalism that the project requires. Upon delivering the rights to use the outcomes of the project PARTNER NAME has to make sure that the outcomes are as faultless as possible. However, the responsibility of the use of outcomes is solely on the beneficiary and PARTNER NAME does not give any guarantees to the beneficiary.

Partners are liable to each other for any damages caused. However, the partners are not mutually responsible for any indirect damages incurred. PARTNER NAME’s liability in every case is AMOUNT AND CURRENCY HERE, unless the damages are due to intentional and gross misconduct, in case of which the liability statements above are void. Claims have to be made within one (1) year from the moment of the incurred damage or from the moment when knowledge of the damage reached the claimant. However, all claims have to be made within one year of the termination of the agreement.

Force majeure is considered as something that prevents or renders the carrying out of the project excessively difficult within the stipulated time. These include war, insurrection/uprising, natural disaster, general interruption in energy distribution, fire, significant limitation of governmental budget or stipulation to the partners’ operations, strike, embargo, or other as significant and unusual causes that are independent of the partners. The partners are not liable for each other’s defects or delays or costs. Neither are they liable for the defects or delays or costs of the subcontractors which are due to insurmountable hindrances.

Each partner has the right to postpone its contribution and terminate the contract in case of a delay caused by an insurmountable hindrance. However, in such case the delay has to be significant. 13. TERMINATION OF AGREEMENT

In case of a partner violating significantly the agreement conditions stipulated in this agreement, other partner retains the right to dissolve the agreement on behalf of the violating partner. ICT PSP Project Reporting

119

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Violating partner is responsible for returning all the data and information that it has acquired based on this agreement to its donor. If a partner is presumably in default, in bankruptcy or in debt restructuring, other partner retains the right to terminate the agreement on behalf of that partner. 14. TRANSFERRING THE AGREEMENT OR ITS PARTS

Partners do not have the right to transfer the agreement or its part to a third party without a written consent. PARTNER NAME can nevertheless use subcontractors to carry out specific tasks. 15. DISAGREEMENTS

This agreement will be applied with the COUNTRY NAME HERE law. Partners shall seek to agree on the disagreements. In case of not being able to agree on the disagreements, they will be settled in COURT NAME HERE. 16. VALIDITY OF AGREEMENT

This agreement is valid from the latest date of signing until the end of the project.

This agreement and its appendices form the total and whole agreement between the partners. Prior agreements or interim talks are not binding between the partners. In case of conflict between the agreement and its appendices, priority is given to the agreement and after that the appendices in order of numbering. This agreement can be altered only by writing.

17. INVALID AGREEMENT CLAUSES

If one agreement clause or condition is found invalid or void, this does not affect other agreement clauses. The partners have to replace invalid clause with such a valid clause that best describes the partners will upon signing the contract. 18. AGREEMENT, AMENDMENTS, AND SIGNATURES

The agreement replaces all prior negotiations, commitments and writings concerning the project described above. Additions and amendments to this agreement have to be made in writing and they become effective, when the partners have signed them. PLACE, DATE

PARTNER NAMES AND SIGNATURES HERE APPENDICES:

PROJECT PLAN, ETC.

1.3 Implementation of the Method The contract agreements should be produced at the beginning of the Plan and Engage phase of the cross border living lab project. These should be done in ICT PSP Project Reporting

120

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

cooperation with partners of the project. The Project Manager/Owner and the possible Steering Group Head should be in charge of developing the contract agreements. The contract agreements should be disseminated to all relevant parties. The following cross border living lab project processes are supported by producing the business model description: • • • • • • •

Identification of partners and trust building among partners and stakeholders

Building project consortium and establishing agreements and contracts

Expectations management: Collecting and aligning stakeholder and partner expectations Stakeholder analysis

Identification and scoping: objectives, results, outputs, dissemination, profit and cost sharing, liabilities, responsibilities, organizing, risk sharing Checklisting for things to consider

Identification of IPR issues, IPR handling.

ICT PSP Project Reporting

121

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

2. Basic contract between test-users and Living Lab Contributor: IBBT

2.1 Tool Description This tool provides a basic contract that can be used between the Living Lab and the test user. It provides a number of elementary elements that have to be taken into account by both parties such as Terms and conditions, Responsibility, Privacy, Liability, Confidentiality. 2.2 Use in practice

The basic contract is structured and drafted in such a way that it creates a general agreement between the test user and the Living Lab. In essence the test-users agree to be part of the Living Lab and engage him/herself in the participation of (various) research project. In this general agreement a number of central elements are defined in terms of conditions, expectations, responsibilities etc… These principles apply for all projects in which the test users will participate. All the project-specific information and agreements are mentioned in ‘annexes’. In those annexes you can determine start and end-date, specific terms and conditions for using a certain device, the costs that are related to this test… The annex also allows to embed bilateral contracts signed between a test-user and a company that is offering a service. This offers a way to deal with certain liability, insurance… issues

Template basic contract

The template contract is split up in the following parts: basic agreement, pilot specific annex and notification and authorization form for gathering personal and privacy sensitive information.

This user agreement establishes all commitments and conditions of the agreement between you (hereinafter referred to as "you", "your", which is taken to mean the person to whom we provide the Device and/or the Application(s), as defined below) and the non-profit NAME ORGANISATION (hereinafter "we", "us" or "our"), located at ADDRESS, registered under VAT number VAT NUMBER (if applicable). What is it for?

As an independent research institution the NAME ORGANISATION carry out interdisciplinary research activities. This work involves regularly conducting field trial projects with the aim of investigating how certain ICT-services are used within ICT PSP Project Reporting

122

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

these field trial projects in the daily lives of the selected test users. We collaborate closely with other institutions and/or companies for these projects.

As a test user, you have opted to participate in a field trial project (“Project”), as described in the Project file in Annex to these user terms and conditions, about which you have already been provided further details.

In the context of this Project the ORGANISATION can provide a device (“Device”) and/or one or more Applications (“Application(s)”). A description of the Device and the Applications is included in the Project file. What is expected of you?

In exchange for the Device and/or the Applications that we provide, we expect a commitment from you to actively participate in the research activities as initially described in the Project file. These research activities are related to studying the use of the Applications and the recording, gathering, processing and analysis of the data and feedback based on this use.

These research activities range from effectively using the Device and/or Applications provided on a daily basis, to participation in group discussions, questionnaires, and potentially other forms of interviews, in order to collect the necessary test user feedback. Costs associated with the use of the Device and the Applications

In principle, we provide you with the Device and/or the Applications free of charge, unless otherwise indicated in the Project file. This means that for the duration of the Project, you do not need to pay for the provision of the Device and/or the Applications. Of course, you will need to pay any costs associated with the day-to-day use of the Device and/or the Applications, such as potential costs for telephone calls, SMS and/or MMS-messages sent and/or received with the Device and data connections. The use of the Device

1) Right to personal use

The Device and/or the Applications, including the intellectual property rights to them, is and remains the property of the ORGANISATION or of one of the partners involved in the Project. You may use the Device and/or the Applications for the duration of this user agreement for personal, day-to-day and non-commercial purposes, subject to the conditions and stipulations of this user agreement. You may not transfer the right to use this Device and/or the Applications to your friends, family, colleagues and/or other persons. 2) Your obligations

You are responsible for the Device and/or the Applications that we provide to you. We therefore trust that you will treat the Device and/or the Applications with the utmost care. This includes respect of the following rules: ICT PSP Project Reporting

123

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

• •

•

You undertake not to modify the Device and/or the Applications, neither in terms of hardware or software and, after the conclusion of the Project, to return the Device and/or the Applications in the condition in which you received it.

You undertake not to use the Device and/or the Applications for illegal and/or other purposes than those explicitly authorised in this user agreement.

You undertake to immediately notify us of any theft, loss or damage to the Device. Moreover, specifically in the case of theft of the Device, you must file a police report as soon as possible and in any case within 24 hours after the theft, and provide us with a copy of this report (official police report).

You undertake to return the Device at our first request, within a period of five working days, so that we can upgrade or adjust the Device or modify or add Applications as necessary.

Interventions of this type may for example be required to ensure the optimal functioning of the Device and/or the Applications or may be in the interests of the Project. 3) Default on your obligations

In the event of theft, loss or damage to the Device, we reserve the right not to replace the damaged, stolen or lost Device and to immediately terminate this user agreement in accordance with article 7.2 of the user agreement.

If we discover that you are using the Device and/or the Applications in violation of this user agreement, we reserve the right to terminate this user agreement and to claim compensation from you for any resulting damages.

In principle you are not liable for damage to the Device and/or the Applications resulting from force majeure. However, if we have already explicitly requested that you return the Device and/or the Applications or if you may have used the Device and/or the Applications for illegal and/or other purposes than those explicitly authorised in this user agreement, you shall be responsible for the consequences of this force majeure. 4) Our obligations

We shall make every reasonable effort to provide the Device and/or the Applications to you as a high-quality product.

However, since the Device and the Applications are being provided to you within the framework of a field trial project, we trust that you will understand that we cannot in any way guarantee the quality, functioning or absence of defects in the Device and the Applications. We therefore exclude, subject to the limitations provided by law, all guarantees, conditions or other stipulations concerning the use of the Device and the Applications, whether they are implicit by law or otherwise, including the guarantee that the use of the Device and/or Applications shall not violate the intellectual property rights of others. ICT PSP Project Reporting

124

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

We are not liable for direct or indirect damages resulting from your use of the Device and/or the Applications. The use and processing of the project results 1) Property of the project results

You agree that all the project results stemming from the use of the Device and/or the Applications, such as for example, recorded user data, shall become our exclusive property. This is important because it will enable us to make optimal use of your test results for our research activities. 2) Processing personal data

All actions you carry out on the Device and/or the Applications shall be recorded individually and linked to your personal profile. The personal data in this profile shall be used by members of the research team connected with the Project and ourselves exclusively after prior notification and with your explicit authorisation, in the manner described in our notification and authorisation form. Confidential Information

In the framework of your participation in the Project, you may gain access to or come into possession of confidential information. For example, we consider the following as confidential information, among others: â&#x20AC;˘ â&#x20AC;˘ â&#x20AC;˘

the Device and the Applications the test results

in general: all information and data that we convey to you within the framework of the Project, including inventions, specifications, models, formulas, programs, plans, drawings, references and standards, financial data, business and factory secrets and all intellectual property rights that belong to us or for which we have obtained the rights to convey or make available.

When you come into possession of or gain access to such confidential information, we expect you to take all reasonable precautions so that, among other things, this information remains confidential. This includes that you do not share the confidential information with other persons or grant them access to it, subject to our written permission in advance.

Naturally, it goes without saying that you shall not use the confidential information for purposes other than participation in the Project.

Duration, termination and modification of this user agreement 1) Duration

ICT PSP Project Reporting

125

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

This user agreement is applicable for the duration of the test period, unless you or we prematurely end it in accordance with the stipulations below. The duration of the test period shall correspond to the period within the course of the Project during which we collect the data necessary for our research activities. The exact duration is indicated in the Project file. 2) Termination and modification by us

In the course of the Project, our needs and priorities may change.

We therefore reserve the right to respond to this by cancelling this user agreement at any time subject to a period of notice of seven days and/or to modify it unilaterally (e.g. in the case of extension of the Test period). You shall always be clearly notified of such cancellation or modification by e-mail, letter, presentation of a statement or in any other manner. In addition, we reserve the right to immediately terminate this user agreement without prior notice, on the following grounds: • • •

If you are not actively participating in the research activities.

If you use the Device and/or the Applications in violation of the stipulations of this user agreement and the Project file. If you lose or damage the Device or if it is stolen. 3) Termination by you

You may also terminate this user agreement in writing at any time (e.g. following modification of these user terms and conditions) subject to a period of notice of seven days.

Moreover, you may explicitly request that we remove from our files personal data that we have processed in your personal profile. 4) Consequences of termination

If this user agreement is terminated by you or by us, you must return all confidential information, including on the Device and/or the Applications, as well as documentation and copies of this documentation to us as soon as possible. In any case, the confidential information, the Device and/or the Applications, as well as all documentation must be restored to our possession within 14 days after the end of this user agreement.

The project results stemming from the use of the Device and/or the Applications shall remain our exclusive property even after the termination of this user agreement. Notification

If you wish to contact us during the Project for any reason, you must do so in one of the following ways, stating your name, address and the details of the Project that your question, comment and/or announcement concerns: ICT PSP Project Reporting

126

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

By letter: By fax: By e-mail:

NAME ORGANISATION ADDRESS ADDRESS FAX-NUMBER E-MAIL ADDRESS

If you do not contact us in one of the above ways, unfortunately we shall be unable to respond to your question, comment and/or announcement. Applicable Law and Dispute Settlement

If a dispute should arise between you and us, before taking legal action, we shall strive to find an amicable solution through direct mutual consultation.

If it is not possible to find a solution, you accept that all claims or disputes with us must be brought before the courts of LOCATION OF COURT, unless agreed otherwise. Furthermore, this user agreement shall be governed by and interpreted in accordance with Belgian law, with the exception of the application of the rules of international private law. Other stipulations

This user agreement contains all agreements and declarations that have been made between you and us related to the matters governed by this user agreement, and replaces any pre-existing agreements which may have been established between you and us with regard to these matters.

The notification and authorisation form is a part of this user agreement and contains additional stipulations on the protection of your privacy. If a stipulation of this agreement should come to be regarded as invalid or unenforceable, such stipulation shall no longer be applicable, without affecting the validity of the other stipulations. This user agreement may not be transferred in part or in full without our written permission in advance. In order to be able to take part in the Project, you must accept the above stipulations. Your name

Your address: Your e-mail address

ICT PSP Project Reporting

127

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Your signature Date

________ / ________ / ________

Annex: Project file 1) Description of the Project

Project name Description

2) Test period

Starting date Ending date

__/__/ ____ __/__/ ____

Description of the Device and the Applications In the framework of the Project, the ORGANISATION shall provide you – for the duration of the test period, as defined above – with the following (strike through non-delivered or non-installed devices):  Devices

Description

Brand

Description

Name

 Application(s) Application

Type

Serial number

Description

Provided

Date of receipt

Free/Paid/….

__/__/____

Provided

Initial description of the research activities Activity ICT PSP Project Reporting

Description 128

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

ICT PSP Project Reporting

129

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

3. Business Model Design for Cross Border Living Labs Networks Contributor: Aalto University School of Economics (AAL)

3.1 Problem or requirement in the WPx addressed by the Method Business Model description is the plan which describes the value envisaged from the cross border living lab project and especially the ways in which that is to be reached. In other words, the business model description captures the value proposition of the cross border living lab project and how that proposition is realized. In this method template, the guidelines for how to develop the business model description as well as its contents (i.e. structure and elements) are described. The development of the business model description should be in the responsibility of the project manager of the cross border living lab project. The need for a Business Model description

In a cross border living lab project environment, the need for the business model description has two dimensions. Firstly, in this environment the business model description is needed in order to create understanding on the actual benefits that are aimed for by engaging in cross border RDI. That is, it is necessary to describe in advance the value that is to be expected from the cross border aspect of a living lab project and especially how that is to be realized. This calls for the creation of an overall business model for the cross border living lab project.

Secondly, in a cross border living lab project environment there is a need for the business plan as in the target country, the diverse business models of the partners in that country are most likely unfamiliar to the client SME engaging in the project. This may lead to a situation, where the kind of knowledge that is targeted to be obtained from the cross border project actually might not be available as obtaining this would violate the business model of a certain key partner. An example of this aspect of the need for the business model description is described in Appendix 1. Therefore, the business model description is needed in order to increase the transparency and to ensure the compatibility of the business models between the project partners, which is then needed in order to assess whether or not the knowledge creation that is targeted with the cross border living lab project will be available in the first place. From this perspective, the project manager of the cross border living lab project should develop or acquire business model descriptions from all the project partners in addition to the overall business model developed on the project level. On preparing the Business Model description â&#x20AC;&#x201C; cross cultural considerations

With regards to the second need for the business model description described above, it can be said that one highly important aspect of this description is that it is intended to serve trust building and transparency between the cross border living lab partners. ICT PSP Project Reporting

130

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

In this respect, the project manager of the cross border living lab project is advised to take into account that the foundations of trust wary between nationalities. This has been argued, for example, by such well known cross cultural management scholars as Susan Schneider and Jean-Louis Barsoux.

Therefore, an a macro level, the cross cultural management scholar Fons Trompenaars has shown in his research that national cultures can be characterized, among others, according to the dimension of Universalism â&#x20AC;&#x201C; Particularism. This cultural dimension is highly salient for developing the business model, as it describes the overall basis of trust in business relationships in different countries. According to this dimension, in Universalist countries (mostly the Western developed economies) business takes place between companies or corporations, that is, trust relations are build between legal entities. In Particularist countries (in Europe usually the former Eastern European countries), business relationships are mostly personal. That is, trust relationships are based on relations and friendship between individuals. Therefore, the project manager of the cross border living lab environment has to take into account that in order to acquire the business model descriptions from the different project partners, he/she must first establish trust either on a company level or on a personal level depending of the national cultural background of the partner.

Another highly salient national cultural dimension in terms of developing the business model description is that of Task Orientation vs. Social System Orientation. This cultural dimension has been developed by another cross cultural management scholar AndrĂŠ Laurent. According to this dimension, countries wary in ways in which individuals or groups can achieve trust by their peers. In Task Oriented countries (mostly Western developed economies) an individual or a group can establish itself as trustworthy by showing expertise in relation to a particular task. On the other hand, in Social System Oriented countries (in Europe usually the former Eastern European countries) trust is often relational in the sense that the peers judge the trustworthiness of an individual or a group by assessing its position in a certain social system or a community.

Building on these notions, the project manager responsible for developing the business model descriptions of the project partners is advised to first asses the cultural orientation of the partners in terms of the aforementioned aspects, and then determine the correct way to establish the necessary trust between him/herself and the different parties in order to obtain the business model descriptions. 3.2 Description of the Method

In this section, the steps of preparing (i.e. building and agreeing on) and the contents of the steps (i.e. the structure and elements) of the business model are described. Hence, a stepwise process of preparing the description is described in the following sections. Each section includes a table with questions and explanations to the questions. By seeking answers to the questions and writing them down accordingly should then produce the business model description as an outcome. ICT PSP Project Reporting

131

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Once again, it is emphasized that due to the above described reasons, the business model description is needed on the overall level of the cross border living lab project, as well as from the different partners taking part in the project. Step 1. Describe the key partners in the cross border living lab project

Every company operates in an ecosystem which includes different kinds of partners. In terms of the cross border living lab project, the importance of these partners is in that each of them contributes to the value creation in the project in their own specific ways. Hence, in producing the business model description it is important that the key partners are identified and especially their role/input in terms of how the value creation in the cross border living lab project is envisaged to occur. Business model item 1.1 Partner identification

Questions to be answered

Explanation

Who are our key partners?

1.2 Selection criteria of the partners

1.3. Contribution of the partner

What are the selection criteria of the key partners? a. Access to critical resources b. Access to critical capabilities c. Technological contribution d. Financial contribution e. Social contribution f. Legal contribution g. Institutional contribution h. End-user/customer contribution Which key activities does each partner perform? a. Introduction to the target country market b. Liaison in the target country c. Provider of technology/component d. Provider of service e. Critical node in the network f. Representative of enduser/customer g. RDI collaborator h. Provider of finance i. Consultation/legal advice

In this section, the project manager should identify and write down all the partners of the cross border living lab project. This should include the involved living labs, large corporations, SMEs, consultants, governmental institutions, research centers, suppliers, vendors, financiers, insurance companies etc. In this section the project manager should identify and write down the main selection criteria of each partner. The point is to assess that the criteria is complementary in the sense that the criteria are not solely overlapping. In the adjacent cell is a list of the most common criteria used to assess the selection of key partners. Here the project manager should then assess the main role of each of the key partners included in the cross border living lab experiment. The perspective of assessment should be that of the value that the project is expected to create and each partnersâ&#x20AC;&#x2122; envisaged contribution to that.

ICT PSP Project Reporting

132

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The above table is designed to assist the project manager in identifying the key partners of the cross border living lab project as well as in identifying the contribution that they are expected to make in the value creation. By writing the questions down to the table, should then provide the project manager with this understanding.

Step 2. Describe the value proposition of the cross border living lab project to each partner In the second step the perspective is changed from that of the Step 1. That is, the partners are not taking part in the cross border living lab project just for the sake of it. Instead, there has to be a value proposition from the project to each of the partners. Therefore, in the second section, these partner specific value propositions have to be identified and described. This is best accomplished by the project manager by taking the stance of each of the partner and trying to identify a key problem for each partner that the cross border living lab project is a solution to. In order to accomplish this switch in viewpoint, the project manager most likely has to engage in negotiations with each of the partners where the project managersâ&#x20AC;&#x2122; task is to â&#x20AC;&#x2DC;interviewâ&#x20AC;&#x2122; the partners for finding out their viewpoints and the way they perceive the cross border living lab project. Business model item 2.1 Partner need recognition

Questions to be answered

Explanation

2.2 Partner problem recognition

2.3 Value proposition to partners

In order to develop the value proposition to each partner, it is useful to start buy considering the needs that the key partners have, and that the project might address. In the adjacent sell is a tentative list of the common needs that the partner might have which should assist the project manager in the identification process. Based on the need recognition, it is then useful to identify a problem in fulfilling that need to which the cross border living lab project might be a solution in each partner. In the adjacent cell a tentative list of common problem areas is described in order to assist the project manager in this identification. Based on the above identification of needs and problems in each partner that the cross border living lab project could be a solution to, the project manager should then be able to formulate a value proposition of the project

ICT PSP Project Reporting

Which key partner needs is the cross border project addressing? a. Business to business marketing/selling b. Business to customer marketing/selling c. Internal process integration d. Outsourcing e. External network creation f. Supply chain integration

Which key partner problems is the cross border project addressing? a. Technological problem b. Marketing problem c. Customer segmenting problem d. RDI problem e. Logistical problem f. Supply channel problem What is the value proposition of the cross border project to each partner?

133

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines to each partner. That should be described in this section.

The above table is then designed to assist the project manager in depicting the value proposition to each partner. Step 3. Describe the key activities in the cross border living lab project

In the third step, the purpose is to describe the key activities of the project. These need not be thoroughly detailed activities. Rather the point here is to recognize that as depicted in the two earlier steps, the project takes place in an ecosystem where the project receives some input from the partners as well as gives them back other things. All this is aimed towards producing the output of the cross border living lab project, which should be described here in the third step of creating the business model description. This is advised to be done by describing the main activities of the project and the overall target they aim at. For this description, the framework depicted in the below table builds on the four key targets identified as the goals of most cross border living lab projects. The project manager is advised to focus the business model description in one of these four target areas. Business model item 3.1 Ecosystem development

Questions to be answered 1. What key activities does the project include in terms of cross border business ecosystem development?

3.2 RDI benchmark development

ICT PSP Project Reporting

What key activities does the project include in terms of cross border RDI benchmark development?

134

Explanation

In some cross border living lab projects the main purpose is to transfer technology from one country to another. In order to succeed in this, the project needs to determine what kind of ecosystem, value network and common approach needs to be in place to do this faster, easier and more efficiently. Therefore, the key activities for determining this should be described here. In some cross border living lab projects the main purpose is to conduct cross border RDI in order to examine the scalability of the product/service. Therefore a common benchmark framework is needeed in order to make the RDI outcomes comparable across borders. Therefore the key activities to establishing this framework should be described here.

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines 3.3 Technological platform development

What key activities does the project include in terms of cross border technological platform development?

3.4 Product/service integration development

What key activities does the project include in terms of cross border product/service integration development?

In some cross border living lab projects the target is to develop and introduce a common technology platform The objective of this is not only to see to what extent the use of such a common platform facilitates the cross border transfer of products and services but also to investigate whether this stimulates new forms of collaboration between different partners. Therefore the key activities for developing this platform should be described here.

In some cross border living lab projects the purpose is to transfer and integrate several locally tested applications into other markets. By deploying the integrated solution in all of the markets enables testing more accurately the advantages, best practices and limitations (on an organisational, technical and research level) of cross-border activities within the network. Therefore the key activities for this integration development should be described here.

Step 4. Describe the key resources needed in the cross border living lab project In the fourth step, the key resources needed from each partner to realize the activities and goals defined in the previous step should be described. Hence, this description should reflect the activities and targets of the cross border living lab project as closely as possible. Most likely the resource needs will change during the course of the project, but nevertheless, it is advised to anticipate them as closely in advance for developing understanding of the overall business model of the project. This step should especially bring to the fore whether the intended business model of the cross border living lab project clashes with those of the partners in some significant way, therefore hindering the possibilities to reach the intended targets of the project. In order to develop this description, the project manager should aim at answering the below questions: ICT PSP Project Reporting

135

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Business model item 4.1 Key resources needed from each partner

4.2 Effect of acquiring the resources on partner value chain/business model

Questions to be answered a) What kinds of resources are required? a. Technological b. Financial c. Legal d. Institutional e. Human resources f. Intellectual properties 2. How is the secure transfer of resources organized? 1.

How does the acquiring of the resources affect the value chain/business model of each partner? a. Organizational effects b. Financial effects c. Technological effects d. Social/network effects

Explanation The required resources from each partner should be described here. In the adjacent cell the most common categories of resources are listed in order to assist this description. The project manager is also advised to describe here how the transfer of resources to the project will be organized. This is a crucial element to describe. Therefore, the project manager is advised to do this with care and reserve some time to do this particular description. It is here where the potential clash between the project and the business model of the partners which could hinder the execution of the project should become apparent. The adjacent cell lists the most common areas where the acquiring of the resources could have an effect in each partner.

Step 5. Describe the cost structure of the living lab project

In the fifth step of creating the business model, the cost structure of the project should be described. This is not so much a description of individual costs rather than a general depiction of what are the main sources of costs in the project. This assessment should be done both on the cross border living lab project level as well as on the level of effects of the project to the partnersâ&#x20AC;&#x2122; cost structure.

In order to produce this description, the project manager should answer the below questions: Business model item

5.1 Cost sources of the project

ICT PSP Project Reporting

Questions to be answered 1.

What are the main sources of costs of the project? a. Technology b. Marketing c. RDI d. Network e. Infrastructure f. Logistics 136

Explanation

The main sources of costs in the project should be described here. In the adjacent cell, there is a list of the most common source areas of costs. The project manager is advised to describe main sources of costs in a general level rather than detailing each and every cost. Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5.2 Effect of the project on partner cost structure

How does the project affect the cost structure of the key partners? a. Organizational effects b. Financial effects c. Technological effects d. Social/network effects

The detailed costs of the project should be incorporated to the actual project plan description. Here the effects of the project on the cost structure of the partners should be described. In order to produce this description, the project manager most likely will have to engage in negotiations with the partners in order to find out their cost structure. As such, this description serves as a way to create trust and transparency between the partners. In addition, this should also serve as a way to assess whether or not the outcomes envisaged of the project are attainable.

Step 6. Describe the revenue structure of the cross border living lab project

In the sixth step, the revenue structure of the cross border living lab project should be described. That is, in order to cover the costs of the project, the sources of revenues should be assessed. However, it is to be noted that this need not solely financial revenues (money). Instead they can be, for example, human capital, technological capital etc. As with the cost structure description, the effects of the project to the revenue structure of the partners should also be described.

In order to produce this description, the project manager should seek to answer the questions in the below table:

Business model item

6.1 Revenue sources of the project

ICT PSP Project Reporting

Questions to be answered 1.

What are the main sources of revenues of the project? a. Technology b. Marketing c. RDI d. Network e. Infrastructure f. Logistics g. Human resources

137

Explanation

The main sources of revenues in the project should be described here. In the adjacent cell, there is a list of the most common source areas of revenues. The project manager is advised to describe main sources of revenues in a general level rather than detailing each and every revenue. The detailed revenues of the project should be incorporated to the actual project plan description. Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines 6.2 Effect of the project on partner revenue structure

How does the project affect the revenue structure of the key partners? a. Partner value proposition b. Partner customer segments c. Partner product /service promotion d. Partner customer retention

Here the effects of the project on the revenue structure of the partners should be described. In order to produce this description, the project manager most likely will have to engage in negotiations with the partners in order to find out their revenue structure. As such, this description serves as a way to create trust and transparency between the partners. In addition, this should also serve as a way to assess whether or not the outcomes envisaged of the project are attainable. In the adjacent cell the most common areas of revenue sources are listed in order to assist this description.

Step 7. Describe the benefits of the cross border living lab project to the project participants

In the final step, the benefits of the project to the participants should be described. This should include the anticipated benefits as well as a general assessment of the potential risks that might hinder achieving these benefits. This description should build on all of the above described steps.

The benefits and anticipated risks should be described in the below table: Business model item

7.1 Benefit identification

7.2 Risk identification

ICT PSP Project Reporting

Questions to be answered 1.

What are the expected benefits of the project to each participant? a. Organizational effects b. Financial effects c. Technological effects d. Social/network effects

What are the expected risks of the project? a. Risks of cross border business ecosystem 138

Explanation

This description should be the overall value proposition of the project. This should also build upon all the aforementioned steps in developing the business model. In the adjacent cell is a list of common areas where the project can have positive effects. This need not be a detailed (e.g. monetary) description rather than an overall statement of the value that the project is intended to create to each participant. A general evaluation of the risks involved in the project should also be included in the

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines b. c. d.

development Risks of cross border RDI benchmark development Risks of cross border technological platform development Risks of cross border integration of product/service

business model. Also this needs not be a detailed description of the risks as that is included in the project plan description. However, a general description of the main risks that might hinder the achieving of the intended benefits of the project should be described here. In the adjacent cell is a list of the common overall areas of risks in cross border living lab projects in order to assist this description.

3.3 Use of the Method The following cross border living lab project processes are supported by producing the business model description:

•

• • • • • •

Identification of partners and trust building among partners and stakeholders Building consortium and establishing agreements and contracts

Expectations management: Collecting and aligning stakeholder and partner expectations Stakeholder analysis

Definition of testing and experimenting

Definition of expected outcomes of the cross border project

Definition of measuring the project/key performance indicators

Producing the business model template should be the task of the project manager of the cross border living lab project. This is best advised to be done in the early stages of the project, that is, preferably in the Plan and Engage phase. The rationale behind this is that this kind of planning for the project should be done as early as possible, because in later stages changes to the project due to improper planning are very costly to make. Appendix 1. An example of challenges met in Apollon WP3 calling for the business model description

In the Apollon WP3 Finnish experiment, it has become evident that there might be challenges for obtaining outcome information from the cross-border experiment. That is, there might be socio-economic-technical characteristics in the Finnish business model within the domain of Energy Efficiency that does not exist, for example, in the Portuguese case. ICT PSP Project Reporting

139

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

This is because in Finland, and in this particular case, in the Finnish/Helsinki socioeconomic context the billing/invoicing by the building owner is made according to the size of each apartment. This includes energy costs. Therefore, if savings in energy costs are achieved through a Living Lab experiment, the building owner should also lower the billing charge per apartment accordingly. It should made the savings public. However, this would lead to a loss of profit to the building owner. Thus, it does not have the imperative to publicize the savings made with the Living Lab experiment.

For example in Portugal, the situation is different within the WP3. In Portugal the WP3 experiment is done among households which have their own energy billing. They have their own meters, the owners are the inhabitants and they know how much they use electricity and how much it costs. Therefore they know it immediately if a Living Lab experiment leads to energy savings, and this will also be an immediate benefit to the households.

Thus, this leads to a measurement problem for the Living Lab and the SME in a cross border experiment: in the Finnish context the foreign SME might not be able to get the outcome information from its experiment. There is a challenge in obtaining information on the success/failure of the experiment. There can be political or economic reasons as to why information from the experiment is not made public. The business model description might prevent something like this from happening as with this kind of description it would be possible to anticipate such difficulties in advance. Therefore, before engaging into a cross border living lab project, the living lab and the SME should ensure that the business model between the planned experiment stakeholders are compatible between the home country and the target country. This also builds towards the common research benchmark: the Living Lab and the SME should ensure that there are no socio-economic-technical characteristics in the target country business model that would prevent obtaining outcome information from the cross border project that is comparable to the home country. Cross border process: Obtaining outcome information in cross border project

Challenge: National business model might hinder obtaining outcome information of LL/SME project

Solution tool: Illustrate national domain/thematic specific business model with in the Plan and Engage phase

In order to answer, for example, the challenge in obtaining outcome information (described above) from the cross border living lab project, the business model template is suggested as a relevant tool. With this tool, when applied in the Plan and Engage phase of the living lab project, the purpose is to increase the transparency between the cross border living lab project partners and, among others, ensure the ICT PSP Project Reporting

140

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

compatibility of the business model between the home and the target country. Hence, this is to make sure, among others, that the domain specific project does not target a national system where it is not possible to obtain the information that is envisaged from the project.

ICT PSP Project Reporting

141

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

4. Policies and Regulations Database Contributor: SAP

4.1 Problem or requirement addressed by the Method The SME partners and the Living Lab in Dresden have never done business before and need to understand about the regulations and policies about how to set-up contracts with local partners, import HW/equipment into Portugal, to learn about tax regulations in Portugal and about agreements between Germany and Portugal, … The Method should provide answers to questions like: •

• • •

How to do business in such a country? Are there any pre-requisites before being able to start doing business in this country, e.g. have a registered local contact/representative ..

Who knows about the relevant regulations to sell a smart meter into the country or would it be easier to find a local HW? What to consider when licensing a SW to a local SME in this foreign country How does “OEM”–like or SW-licensing contracts look like in that country

4.2 Description of the Method Steps it may require: •

Identify the industry & the business segment/purpose SME is targeting at; maybe according to the World Banks “doing business indicators”: http://www.doingbusiness.org/

o The Doing Business Indicators are comparable across 175 economies. These indicators include starting a business, dealing with licenses, employing workers, registering property, getting credit, protecting investors, paying taxes, enforcing contracts, and others.

o The Doing Business Project provides objective measures of business regulations and their enforcement across 183 economies and selected cities at the sub-national and regional level.

o The Doing Business Project, launched in 2002, looks at domestic small and medium-size companies and measures the regulations applying to them through their life cycle o This year’s report covers 11 indicator sets and 183 economies.  

Starting a business: Procedures, time, cost and paid-in minimum capital to open a new business Dealing with construction permits: Procedures, time and cost of obtaining construction permits, inspections and utility connections

ICT PSP Project Reporting

142

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

   

   •

Registering property: Procedures, time and cost to register a transfer of commercial real estate

Getting credit: Strength of legal rights index, depth of credit information index

Protecting investors: Indices of the extent of disclosure, extent of director liability and ease of shareholder suits

Paying taxes: Number of tax payments, time to prepare and file tax returns and pay taxes, total taxes as a share of profit before all taxes borne Trading across borders: Documents, time and cost to export and import Enforcing contracts: Procedures, time and cost to resolve a commercial dispute in court Closing a business: Recovery rate in bankruptcy

It is not sufficient just to have the Link to a knowledge base, but also to have a network of experts available, who can consult on those questions, means interpret those policies & regulations and to help to comply with them:

o Get in touch with the right local experts (or even get them connected to the Living Lab as soon as you see you will need them more often) o Monitor the consulting by the experts to the SME.

4.3 Use of the Method

Now when we think about how to really get into business after the research project, we will for learning & preparation purposes use the 2nd phase of the project to do as if we would like to start a business of the “licensing across borders and setting up a local smart metering monitoring service” Find out, if it would be possible to set-up such a business and evaluate the potential business case 4.4 Implementation of the Method

We are introducing it to the partners of the eManufacturing pilot in regular call series and will follow-up on it in our weekly call series: start to walk through the above mentioned steps, check whom we need to involve, what needs to be done, describe & document the correct steps & activities, .. and execute, as if …

Activity

Responsibility

Introduce the method to the WP 4 partners

WP4 & WP 1

Identify & describe the business (doing business indicator)

Deadline

cw 19/20

Collect available information sources, prioritize ICT PSP Project Reporting

143

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Identify where we need the help of experts

Review the network, identify sources for experts search, collect possible & relevant experts identify & describe necessary activities with the help of available sources Get in touch with experts

Review activities described with help of available sources, identify gaps & misunderstandings with the help of the experts Adjust & finalize list of activities to be done to realize the above mentioned service “licensing across borders and setting up a local smart metering monitoring service” Document process, sources, experts

Evaluate process, sources & experts with the service “..asset monitoring”

M28 M30

4.5 Example of the Method • •

• •

http://www.doingbusiness.org

https://www.ebundesanzeiger.de/ebanzwww/wexsservlet?session.sessionid=e 1c01081d06ba8caeb44edccf9a50b57&page.navid=to_knowledgeable_howwork_content&global_data.designmode=eb#a_1 http://de.wikipedia.org/wiki/Bundesanzeiger

http://www.bu.edu/library/guides/pml/countries/portugal.html. See next page on the BU Libraries structure of the international Business Database

ICT PSP Project Reporting

144

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

BOSTON UNIVERSITY LIBRARIES International Business: Country Portugal Country Descriptions & Profiles Finance, Trade & Commerce News & Journals Statistics & Government Resources Country Descriptions & Profiles Background Notes on Countries of the World: Portugal in Business Source Complete [ About ] Published by the U.S. government and includes facts about the land, people, history, government, political conditions, economy, foreign relations and travel/business information. OECD Economic Surveys: Portugal [About] Organization for Economic Co-operation and Development provides statistics and report on its 30 country members in addition to various reports, statistics and working papers covering macroeconomics, trade, education, development and science and innovation with approx 70 countries it has relationships with. Content vary country by country. Offical Site of Portugal http://www.visitportugal.com/Cultures/en-US/default.html Portugal Country Profile in Business Source Complete [About] Provides quick access to country data points, trends and analysis including country's political and governmental make-up, economic performance, gross domestic product, the potential for economic development, and detailed market and industry analysis of the country's business environment. Portugal Country Review in Business Source Complete [ About ] Published annually by CountryWatch, these in-depth reports provide demographic, political, economic, business, cultural and environmental data. Includes key sector production, consumption and net exports, maps, country flag, Freedom Rankings for political rights and civil liberties, Human Development Index measuring quality of life and investment climate basic infrastructure information. Finance, Trade & Commerce BuyUSA.gov U.S. Commercial Services: Portugal http://www.buyusa.gov/portugal/en/ From the U.S. Department of Commerce, International Trade Administration. U.S. Commercial Service (USCS) Provides information to U.S. ICT PSP Project Reporting

145

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

businesses exporting goods and services, including trade agreements, market research, trade event lists, industry specific information. Doing Business. Benchmarking Business Regulations. http://www.doingbusiness.org/ Produced by the World Bank, this database provides information on business regulations and their enforcement in many countries. Countries are ranked according to ease of doing business. The Doing Business Indicators are comparable across 175 economies. These indicators include starting a business, dealing with licenses, employing workers, registering property, getting credit, protecting investors, paying taxes, enforcing contracts, and others. EIU: Economist Intelligence Unit: Portugal [About] Indepth reports such as Country Finance, Country Commerce, Country Forecast, Country Monitor, etc which include economic indicators, political and business environment analysis, country risk assessment and financial and operating conditions for companies doing business globally. Type of reports vary country by country. FITA: Portugal Country Profile http://fita.org/countries/portugal.html FITA, The Federation of International Trade Associations, website includes general information as well as information on market access, economic indicators, taxes, labor market, agriculture, media, and more. Global Edge: Portugal http://globaledge.msu.edu/ibrd/countryintro.asp?CountryID=69 Created by the Center for International Business Education and Research at Michigan State University ( MSU-CIBER ), globalEDGE contains country specific news, statistics, history, economics, and government data. Index of Economic Freedom: Portugal http://www.heritage.org/Index/Country/Portugal A Web resource evaluating the following areas: Portugal's trade policy, fiscal burden of government, government intervention in the economy, monetary policy, capital flows and foreign investment, banking and finance, wages and prices, property rights, regulation, and black market. Portugal Country Monitor (Global Insight) in Business Source Complete [About] Presents Analyses, Statistics, and Forecasts on the Economy. Includes information on Gross Domestic Product (GDP), Real GDP, Consumer Prices, Foreign Trade, Official Exchange Rate, etc. Also provides Import and Export Statistics as well as the names of important government officials. Portugal Economic Competitiveness in Business Source Complete [About] From the Icon Group, using vertical analysis or common-sized statements, provides estimates of the financial performance and labor productivity of countries compared to global benchmarks. Financial analysis includes asset, ICT PSP Project Reporting

146

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

liability and income structure, ratios, profitability ratios and key percentile rankings. Labor productivity analysis includes asset-labor, liability-labor, and income-labor ratios. Political Risk Yearbook: Portugal Country Forecast in Business Source Complete [About] From PRS Group, published annually and includes the Political Risk Service rating system which assesses different political scenarios within a country, 18month and five year forecasts based on a variety of political scenarios, the country's political framework, key political player as well as economic conditions, investment, taxation and environmental trends, foreign relations, defense forces and the country's history and geography. News & Journals Autosport (Portugal) through PressDisplay [About] Expresso through PressDisplay[About]

from 60 days ago.

Expresso Actual through PressDisplay[About]

from 60 days ago.

Expresso Economia through PressDisplay[About] Expresso Unica through PressDisplay[About] Portugal News through PressDisplay[About]

from 60 days ago.

from 60 days ago. from 60 days ago.

The Wall Street Journal Europe through PressDisplay[About] ago.

from 60 days

Statistics & Government Resources Banco de Portugal http://www.bportugal.pt/en-US/Pages/inicio.aspx The official Web site of the Bank of Portugal includes information on currency rates, monetary policy, statistics and much more. Statistics Portugal http://www.ine.pt/xportal/xmain?xpid=INE&xpgid=ine_main The official statistical office for the country of Portugal. Embassy of the US to Portugal http://portugal.usembassy.gov/ -----------------------------------------------------------------------------------------------Country Specific Sources Region Specific Sources General Country & Region Sources

ICT PSP Project Reporting

147

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5. Contacting and Profiling Platform on Knowledge Center Contributor: Aalto University School of Economics (AAL) 5.1 Objective of the Method

This particular method or tool takes care of a number of different problems that have been reoccurring in the process of cross border living lab experiments. The dificullties in finding partners coupled with the limited ability to present living labs in a standardized form at a single location have led to the development of the conceptual contacting and profiling platform on the knowledge center. specific functionality includes the ability to search, select and contact using prefilled forms.

The Tool under development contains fills the needs for the following functionality: • • • •

SME partnership search and selection

Profiling of living labs and SMEs for finding partners Needs finding, partner search and tendering Contacting of potential partners

5.2 Problem addressed by the Method There is a problem for SMEs who are looking for the correct Living Lab to do the research that they aspire to have done. This problem is that the Living Labs have no standard to present themselves with, no place to demonstrate their specialization and no place to be found. This problem is present from several angles; • • • • • • •

It are the Living Labs who fail to be easily found

It are the SMEs who cannot judge what a living lab can do because there is no place to see their capabilities or to compare living labs with each other

It are the SMEs who fail to ask the right questions when searching for a living lab there is no standard method for contacting one or several living labs that is recognizable to all parties

There is no tendering possibility for projects, project partners, conferences etc.

There is no contact database available for people to contact

There is no place where Living Labs can “promote” earlier projects to demonstrate their abilities

5.3 Which process is supported by the Method?

The main processes supported with the Contacting and profiling Platform are the processes in the early stages of the setup of the network and the dissemination of results via the past projects promotion. ICT PSP Project Reporting

148

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

At a first level the platform functions as a presentation and searchable database

In the above presented process cycle, the Connect phase in particular and the plan and engage phase to some extend will benefit from the possibilities that the contact and profiling center offers.

At the second level (deeper), the platform can help in building networks for projects by providing parties looking for partners a system of contacting potential partners with pre-filled forms containing the needed and detailed information concerning the envisaged project. This can be done in a single, directed approach following from a number of questions to be answered, leading to a completed suggestion for cooperation, or, by a public tender, where the information concerning the project is provided to the to all potential partners, both as a direct mail and in a section (to be created) that can function as a “market” for new projects. 5.4 Description of the Method

 SME partnership search and selection

In the process of partner finding for new network setup one of the main constraints is the fast retrieval of relevant information about potential partners. When a Living Lab or SME looks for a partner with particular abilities the search function will provide help. For living labs the presence in the Knowledge Center helps them in profiling to an international audience and can be used to demonstrate their participation in ENOLL.  Profiling of living labs and SMEs for finding partners

The profiling section of the living lab is at present the most advanced function available on the contact and profiling platform. The options that are available are;  general information o name ICT PSP Project Reporting

149

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

o logo o location pointer o web address o email contact o address of organization o country of action o membership of network o names of coordinating partners o scope and focus of project in geographical terms ď&#x192;° available services on management o matchmaking services o project management services o funding advice and services o legal support (advice) and services o cross border collaboration management and support services ď&#x192;° product (service) development and support o focus of research o available facilities o access to users o experimental methodologies

These characteristics are selectable and at many places can be searched by visitors. These characteristics are specifically for describing the organization and its capabilities.

ICT PSP Project Reporting

150

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

A different section on the platform is dedicated to specific living lab projects. At present the description is possible in the following characteristics      

type and description of research partners involved phase of research type of tools used approach to product/service methods of user involvement

These need to be extended with links to the possible partnership and tendering pages still to be constructed.  Needs finding, partner search and tendering ICT PSP Project Reporting

151

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The Needs finding and partner search/tendering is still under construction. In the finished site there will be two methods for this function. 1. The search function

At present there is the possibility to search for partners in the database of living labs and registered other parties. this search can be done according to the characteristics desired.

2. The tendering function

In the future there will be a form with a series of questions; • • • • • • • •

what type of project

what expected start date what duration what domain

where geographically what language

what type of user needed what funding is available

o what is expected from partners

ICT PSP Project Reporting

152

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

o does any of the aforementioned information contain confidential information

Based on the answers to these questions, a completed form with information concerning the asking partner, retrieved from the profile of that partner, and specific information from these questions, will be made and send to the living labs or organizations that are the best match to the needed qualities. To this mailing the approached partners are able to respond and start with the planning of a project. (using the other tools) ď&#x192;° Contacting of potential partners

The website contains contacting information for all registered parties, both living labs and organizations related to living lab research. This information is available to all parties who have registered on the website and is searchable. Promoting completed projects as part of the profiling

The living labs are at present able to link to their websites, and via the living lab project functionality they can demonstrate ongoing projects. there will be an searchable archive function. 5.5 Use of the Method

Supported process; connect phase, manage and track 5.6 Implementation of the Method To be decided.

ICT PSP Project Reporting

153

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

6. Framework for Value Analysis Contributor: IBBT

1.1 Problem description

Performing a pilot in a living lab requires the involvement from different stakeholders. The triple-helix, as a reference to the collaboration between the three institutional partners (government, industry and universities) is one of the corner stones in the Living Lab set up. Moreover, there is even a fourth important actor involved in these type of projects, namely the user (therefore we do even speak form a quadric helix). One of the objectives of Living lab pilots is that they conduct pilots or experiments within the natural setting of the actors involved. To do so, and not opt for a traditional lab-setting, the Living Lab is able to check the different conditions, impactâ&#x20AC;Ś of the service, product or process under evaluation. This context and the interaction within allows you to evaluate and value the services in the most extended way.

However, to set this up, it requires the involvement of the various stakeholders that represent the current or future eco-system in which the product or service will be commercialized. In order to guarantee that all partners are collaborating and willing to experiment (meaning that they will have to invest in the project) during the Living Lab pilot, it is absolutely necessary that there is a clear benefit for each of them. When there is a win-win for all, stakeholders are motivated to participate actively till the end of the project. Therefore it is important that the project generates sufficient added value. To be able to identify what each partner wants to gain out of the pilot it is good to perform a value analysis for each partner. To objective of this exercise is to list the expectations of every stakeholder involved and by so the desired outcomes. The results of this should be then reflected in the set-up of the pilot to ensure the fully commitment and participation of the partner. 1.2 Method description

A value analysis is a way of identifying the values and expectations of the stakeholders in a project in order to be able to make strategic and operational decisions. Stakeholder value analysis involves identifying groups of stakeholders and eliciting their views on particular issues in order that these views may be taken into account during the project.

ICT PSP Project Reporting

154

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The goal is to articulate the role of each stakeholder, its primary objectives, its specific needs, and the inputs it receives expects from the other stakeholders. To do so, you will have to do the following: 9

1. Identify Stakeholders. Start by identifying all possible stakeholders. These could be individual persons or stakeholder groups.

2. Determine the importance of each stakeholder. Look at each stakeholder and determine how important he or she is to the success of your project. You might categorize each stakeholder in terms of high/medium/low importance. This evaluation is important because sometimes you spend too much time and effort working with stakeholders that are of low importance to your project, while short-changing the time you spend on stakeholders that are very important.

3. Identify the interest of the project for each stakeholder. This is where the analysis starts. Stakeholders have a stake or interest in your project. Now you have to identify what this stake or interest is. In some cases the stakeholder might need something from your project team. In other cases, you may need something from them.

4. Determine how you will engage each stakeholder. For each stakeholder, you should identify a set of activities or even an overall approach for getting them engaged. You should identify activities that help you to achieve your interest while also recognizing the relative importance of each stakeholder group. Obviously you will spend more time working with stakeholder groups that are important to your project and less time on groups that are of low priority. 5. Gain agreement when necessary. In some cases, stakeholders want things from your project. However, in other instances you need something from them. If you need something from the stakeholder or stakeholder group, make sure that they understand what your expectations are and make sure that they agree to provide what you need.

6. Move the activities to the pilot set-up. You don’t want to keep a separate stakeholder activity spreadsheet. After you identify the activities to engage the stakeholder groups, place all of the activities in the project workplan, along with who is responsible, the timeframe, estimated effort, etc. To investigate to what extent they are willing to participate and what their main drivers is to do so, following questions can help: •

•

What main interest do they have in the outcomes of the project (potential business, financial benefit, lessons learned…)?

What motivates them most of all? To what extent is it in line with their current business, way of operating or roadmap?

Mochal, T. (2006). Use stakeholder analysis to meet the needs of all interested parties. http://www.techrepublic.com/article/use-stakeholder-analysis-to-meet-the-needs-of-all-interested-parties/6077367. Last consulted on February 5, 2012

ICT PSP Project Reporting

155

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • • • •

How strategic is the participation of the pilot with regard to their activities / roadmap)?

What do they want to gain at the end of the project (on the level of the project results or with regard to the other stakeholders that are involved)? How do they want to receive information from you? What is the best way of communicating your message to them?

What is their current opinion on the project scope?

What is the (possible) win for them in participating to the project and what is the win for the other stakeholders? How strategic are they? What if they would not participate (anymore) in the pilot?

Performing a value analysis will lead to: •

•

A high partner orientation, focusing on those aspects of the product/service that fits more with the current or future objectives and operation of the stakeholder and the pilot.

More efficient by identifying and eliminating aspects within the pilot that are not in line with the various activities of the stakeholders in the eco-system and that do not supply specific added value. Challenging the current way of thinking or operating of the stakeholder by engaging them experiments in which they are confronted new next designs of new products or to systematically improve the existing ones.

ICT PSP Project Reporting

156

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Stakeholder value analysis for table 10 Stakeholder

Characteristics

Main interests

Impact on situation

Interests, fears, expectations

Relation to project

Potential impact

Recommendations

Priority

identity of group or individuals

what sort of person or organisation are they?

what are their main interests or motivations?

what impact do they currently have on the situation the project is interested in?

what is their reaction to the project likely to be?

what is most likely position that they will adopt vis-Ă -vis the project?

how important or serious might consequences be for the project? (low, med, high, critical)

Implications of this for the project plan

Rank importance of stakeholder to project success (high, med, low)

IBA. (2007). Guidelines on Stakeholder analysis. http://birdlife.org/ibas/5_conservationaction/Stakeholder_analysis_guidelines.pdf. Last consulted on February 5, 2012

D1.4 Recommended Toolset and Collaboration Guidelines

7. Requirements Analysis 7.1 Problem description When setting up a cross-border pilot a good preparatory exercise is mandatory to determine the specific goals and expectations. A thorough listing of all the pilot requirements is a necessity. This listing is not limited to the technical specifications that are required for the pilot, but it also necessary to focus on operational issues (deployment), organizational aspects as well as on the level of the research.

Identifying pilot requirements is an iterative process in which (although partly part of the exercise itself) as much stakeholders as possible are involved from the start. It is a process that takes time. In our experience you will have to at least count a period of 1 to 2 months to have a very good requirements description. The objective is to be as thorough and detailed as possible. By doing so, you will identify possible issue of the pilot up-front instead of during the pilot. By so you will be lower the risks of having unforeseen issues during the pilot that are non-solvable or that occurs after the point-of-no-return. 7.2 Method description

Based on our experiences within the Apollon project we have created a framework that can act as a steppingstone or guide to perform a thorough requirements analysis in the early stage of the project. 1. Defining the context 1.a Creating a scenario

To act as a guideline at the start it is useful to define a scenario in which the set-up of the pilot is reflected. A scenario is a description of a person's interaction with a system. Scenarios help focus design efforts on the user's requirements, which are distinct from technical or business requirements. Scenarios may be related to use cases, which describe interactions at a technical level. Unlike use cases, however, scenarios can be understood by people who do not have any technical background.

The scenario has to be a step-by-step approach of how the system is being used in real life. To built this scenario you are obliged to identify the different stakeholders and their specific roles. For the creation of the scenario you will have to take into account the perspectives of the various partners. 1.b Description of the technical set-up

Based on this scenario a schematic description of the technical set-up has to be defined. This has to cover as much as possible the various components that will be subject of the pilot and how they interact or coupled with each other. In the same exercise a first allocation of the who will take care of certain aspects is needed 2. Requirements

D1.4 Recommended Toolset and Collaboration Guidelines

Often requirements are only defined on a very technical level. But it is also necessary to list the requirements on the organizational and research level. 2.a Technical requirements

The technical requirements best start with a detailed description of the service or product subject of evaluation. What is it that you would like to evaluate, transfer? It is not sufficient to use the standard technical description (if available). The goal is to be explicit as possible. A breakdown of the system in the different subparts (and describe those) is in that sense necessary. Don’t just state that you need an internetmodem and a webcam – but describe the specs of the modem and those of the webcam separately. In order to have a good understanding of the requirements it is useful not only list what the system does, but also what the system, service or product is not able to do or to operate in/on. Second it also important to list the technical requirements expected from the different parties that are involved. In other words, it is not sufficient that the technical partners that are involved describe the various specs. But also what is expected from the user? For example, does (s)he has to have a broadband connection? And if so, what are the specifications of that? The same applies for the intermediary organizations? What has to present at their organization? Does it have to interact with existing systems?

Important in this process is not to assume that people have the same perception of something. A broadband connection in one country is not the same as in another. Therefore don’t just state: “a broadband internet connection is required” but give as many details as possible that might be important (eg. minimum speed, type of IPaddress, NAT or not etc…) Finally, you need based on the scenario and the technical set-up identify the interconnections between the various parts of a system. This is not only on a technical level (how do we transfer data from a to Z or how do we connect a certain part with another) but also on the contextual level (where will be the system be used and how does it interact with that environment) 2.b Installation requirement

Often when introducing a new service or product, especially in cross-border pilots it is not just handing a specific product to one stakeholder. If mostly requires that at various stakeholders (eg. user, intermediary organization, the living lab…) different parts of the service or product need to be installed (for example when introducing a video-monitoring system – you wll have to install a set-up at the test-user, but you will also have to equip the care-organisation that will handle the calls with the proper instruments). Therefore it is needed to identify for each stakeholder what will need to be installed or present. What are the various requirements and specifications for each of this set-up. In other words, you will need to describe in detail the specific set-up for each partner in which not only the technical aspects are listed, but also the implications on the organizational level (eg. does the call-center has to be staffed 24/7) ICT PSP Project Reporting

159

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

2.c Organizational requirements: support and helpdesk

It is not only necessary to address the issues with regard to the installation and deployment of a service and technology. You will also have to identify how you will organize support to the various stakeholders during the pilot. Especially during cross-border pilots this is something you will need to describe in detail. How do you foresee the support: will this be done remotely by the offering partner or do you need to have a local partner that can take care of these issues? How will you detect the issues? How will test-users be able to report issues with the system or service. For each of the components in the set-up this has to be described. This also helps also in (1) the identification of the eco-system (are all necessary partners include) and (2) the definition of the specific roles and responsibilities of each partner. 3. Research set-up

3.a Objectives and goals

In the pilot requirement analysis a major element to identified are the needs with regard to the research underlying to the pilot itself. It is good to have a very, as detailed as possible overview of the research set-up. This starts with a good definition of the objective and goals – what do you want to achieve with the pilot. Based on that you can start list the various aspects that have to be in place to enable this. Immediately this involves a feasibility study that assess to what extent you will be able to obtain the given research objectives. What is required in terms of timing, methods, tools, users? 3.b Research Requirements

To define the research requirements you will first need to define a research methodology in which you describe the set-up of the research, the type of methods you will, the target audience, the interaction with that audience… A good way of doing so is to create a research timeline on which you map the various research steps. For each research steps you will then define what is the objective and what is required (tools, methods, data….) and by whom. In the research requirement you need to pay attention to the following elements: •

•

The user: who is your target research panel, how will you interact with them. Especially the latter is a crucial element in terms of cross-border pilots (it will not be easy as foreign partner to interact closely with a target group that is active in another country) and pilots within the domain of health and well-being (you will need a trusted party to interact).

The timeline: when will which research part be executed and what is required for that by that time. As mentioned before, next to the overall gannt chart on the pilot level you also have to make a timeline specific for the various research activities. In cross-border pilots often different partners are involved in the process, such as local living labs or intermediary organisations. They will have to embed this also in their regular activities. Such a timeline is not only a planning

ICT PSP Project Reporting

160

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

tool, but also act as an overview tool to determine what is expected from which partner.

The data-gathering: How and by whom will the data be caputered. Will this be done remotely via technical tools (eg. logging) or do you need personal interaction with the test-users? It is also not only about drafting a questionnaire, you will also need to contextualize (translations, tune to the specific targetgroup) them. Next it is important which trusted party will execute these activities. If it are trusted parties, which in the domain of health and well-being is crucial, you might have to train this people… Data-sharing: Finally – as often in cross-border the research is done remotely and with different parties a good way on how the collected data will be shared amongst the parties. This is not only about the transfer of the data in itself, but rather on the interoperability of data, the (re-)use in various systems, the format as well as to what extent it is in line with local privacy regulations. Especially with the exchange of sensitive data (eg. medical) the local rules and regulations differs and are often very strict.

4. Initial required eco-system

Based on the above analysis, the final step in the pilot requirement analysis is to design an initial required eco-system. To do so you need first to list all the task and activities required for the pilot execution based on the overviews of the previous steps. Subsequently you start to match the actors that will take responsibility for the various activities. If this is covered you will finally list all the various partners that need to be involved and you describe for each one in detail its role, responsibility and position within the pilot. In a cross-border pilot you will have to address this initial eco-system on the whole pilot set-up and not subdivided in the various context or regions. Starting from the local, existing eco-system can be useful.

In doing a cross-border pilot, you will need also list the specific cross-border issues in this eco-system overview. Here you address all the aspects and adjustments that are required to enable the pilot deployment in the other region or context. Is the system compliant with standard rules and situation (eg. are the electricity plugs the same), is there a translation of the interface required, providing access to certain actors… Next, again within the context of cross-border pilot you will need to identify any (possible) legal issues. This is related to the access and exchange of (private) data, to what extent medical data is involved and has to be treated. By identifying you are able decide who will have the responsibility on the data-sets, which agreements have to set-up and between whom, what kind of permissions you have to request for (eg. ethical approval…) 5. Expectations

From the initial contacts with the various stakeholders identified in the eco-system exercise, it is a necessity to, from the start, try to identify the different stakes of all partners. Having a good understanding of everyone’s expectation with regard to the pilot is necessary for (1) know the desired outcomes, (2) knowing the specific ICT PSP Project Reporting

161

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

contributions they are willing to do and (3) to fine-tune the scope and objectives. Important is to find the right balance between each interest and to create a win-win for all stakeholders. A value analysis for each of the partners identified in the ecosystem is therefore recommended.

ICT PSP Project Reporting

162

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8. Decision and Management Support Framework Contributed by: Aalto University School of Economics 8.1 Problem addressed

Different stakeholders decide to explore the opportunity of a cross border living lab network. The cross border network, once in place, may conduct RDI, market creation activities and technology transfer activities. The cross border living labs network covers a life cycle of phases: inception, definition, operation, sustainability or termination. What is needed from point of view of decision and management instruments? 8.2 Decision and management needs

We focus on the following distinctions addressing different concerns: •

•

Guideline for deciding on creation of the network. This guide supports potential stakeholders in identifying and evaluating the business opportunities and prepare a general plan and justification for setting up the cross border living lab network. As this is a strategic decision, this would have the character of a business plan or strategic plan. Based on the plan a go or no go decision will be taken. Guideline to develop a network development plan. Once the decision has been taken to establish a cross border living labs network, a plan is needed to guide stakeholders towards its development and implementation. This plan would cover activities such as partnering, developing a business model, contracting, elaboration of the network structure, launching the network. Each of them require decisions and tools to support decisions (e.g. partner selection) but that will be covered in the other methods and tools. What is important here is to set out and agree on the network development plan.

Guideline for detailed planning of the network. Partners have been selected and agreements reached. Now the living labs network must be detailed, including organizational, procedural and governance arrangements such as roles and responsibilities, IP, resources etc. This might also be included in the network development plan (above), if appropriate. Guideline on managing the operations of the network. The cross border network of living labs, once in place, will conduct activities such as joint RDI, market creation and technology transfer. These might be called projects and for that we need project management. For example the Homecare pilot is a project to transfer technology from Belgium to Finland and Holland to Spain. Managing these projects is highly relevant. A particular case would be that a temporary living lab network is set up for one goal, to transfer the technology, then terminated. This would imply that network creation and operation comes together in one business case.

ICT PSP Project Reporting

163

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8.3 Strategically deciding on network creation Here we need a method or business plan to support the strategic decision to invest in a cross border living labs network. Ingredients of such network creation business plan will be the following: • • •

• • •

Business opportunity identification and analysis Business case (investment decision from stakeholder perspective) Business model (justification of value creation; value proposition, customers, financial model) Sustainable implementation strategy Environment and risks analysis Organisation and governance.

Cross border aspects will be central in the following aspects: • • • •

Analysis of the environment, e.g. regulations Risk analysis of cross border collaboration Organisation and governance of the network Factors determining sustainability.

8.4 The network development plan

We may distinguish between primary development activities and supporting structures. Primary development activities that should be described (and how to handle them) include: • • • • • • •

Rough planning of the living lab network (structure, competencies, capabilities) Partner search and selection Negotiation Business model evaluation Detailed network planning Contracting Network launch.

Supporting structures and processes include: • • •

Organisation, governance and management of the network Planning and management instruments Infrastructure for collaboration and knowledge management

For all these we need to focus on cross border issues and how to address them. Such cross border aspects include: • • • •

Rules and legislations regarding IP and contracts Identifying trusted partners in cross border business Cross border governance and management issues Cultural issues in negotiation and agreements finding

ICT PSP Project Reporting

164

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

8.5 Managing the network operations, project management Network operations can be very specific and a specific pilot can be considered as a project for which a project plan will be necessary. The broad elements of the project plan for transfer of a technological solution will include the following: • • • • •

Project definition, goals, KPIs Activities

Resources

Project governance (roles, responsibilities) Risks and environment.

Cross-border issues that may be covered include: • • • • • •

Cross-border oriented risks e.g. partnership conflicts, contract break, PR problems Different cultures of collaboration, conflicts, delays Differences in value networks, roles, institutions

Different environmental conditions e.g. legislation, regulatory environment Business model cross border prospects and determining factors

Collaboration infrastructures to facilitate cross-border project management.

8.6 Managing the cross border living lab network

In comparison with living lab projects taking place within a particular country, the cross border living lab networks have one significant difference: these are projects conducted within a network of participants having different national cultural backgrounds. Therefore the managing of these projects has to be culturally contingent.

During the past four decades, the international cross cultural management research has strongly brought forth that management and decision making practices have to take cognizance of the national context – even within the EU. Since the international expansion following the World War II, the implications of cultures and cultural differences on management, organizing, and organizational practices have become visible and increased in salience. Already by the works of Haire et al. (1966) it has become obvious that management and business practices differ between countries due to factors with cultural features and properties. These seriously question the idea which has traditionally been predominant, i.e. that management and decision making could be based on universal practices of organizing and management and that the same organization and management practices could be applied anywhere and everywhere without paying attention to the national context. Instead, organizing and management has been shown to be culturally and nationally contingent. For example, research has shown how project management practices ICT PSP Project Reporting

165

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

and styles differ between national cultures. In a similar manner, for example, such highly important aspects of cross border living lab network operations as risk management practices as well as conflict management differs culturally. Managing cross cultural teams and establishing trust is culturally dependent. National cultures also have an impact on national institutions such as, for example, financial systems, legislation, and law enforcement. Recognizing national cultural differences

The cultural contingency of managing and making decisions in cross border living lab networks then calls for the need to be able to recognize and distinguish cultural differences between countries. For this purpose, different universal frameworks have been developed, which have also been validated in countless occasions within the academia and global business world. The most well known framework for identifying national cultural features is, without a doubt, the one developed by Geert Hofstede (1980). This robust framework builds on the idea that each nation possesses a unique, shared combination of universal societal values that could be used as an embodiment and an expression of that particular country’s culture. In addition, these values can be categorized according to a finite set of universal value dimensions, and most importantly, by means of arithmetic reductionism each particular country can be given a relative position along the culture dimensions. Consequently, this kind of dimensional positioning creates the basis for an objective, universal terminology according to which national cultures and their properties can be distinguished, characterized, and their differences observed and compared.

In this framework, four universal value dimensions comprising of the national culture are distinguished. These are called individualism/collectivism, power distance, uncertainty avoidance, and masculinity/femininity. According to Hofstede, these are the value dimensions according to which national cultures differ between each other, and which can be used as a basis of cultural identification and recognition.

According to Hofstede, in individualistic countries, ‘a loosely knit social framework in which people are supposed to take care of themselves and of their immediate families only’ exists, while a collectivistic country ‘is characterized by a tight social framework in which people distinguish between ingroups and outgroups, they expect their ingroup to look after them, and in exchange for that they feel they owe absolute loyalty to it’ (Hofstede, 1980b, 45). Therefore, individualism ‘exists when people define themselves primarily as separate individuals and make their primary commitments to themselves’ (Adler, 1997, 47). On the other hand, collectivism ‘is characterized by tight social networks in which people strongly distinguish between their own groups (in-groups, such as relatives, clans and organizations) and other groups. Collectivists hold primarily common goals and objectives, not individual goals focusing exclusively on self-interest’ (Adler, 1997, 47). The United States is commonly held as an example of an individualistic culture, whereas the Middle-

ICT PSP Project Reporting

166

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Eastern and Asian cultures are commonly seen as collectivist. Both of these also appear within the EU.

According to Hofstede, power distance refers to ‘the extent to which a society accepts the fact that power in institutions and organizations is distributed unequally’ (1980b, 45). Hence, in organizational behavior Power Distance measures ‘the extent to which less powerful members of organizations accept an unequal distribution of power’ (Adler, 1997, 51). It indicates societal, culturally shared understanding to such questions as ‘[t]o what extend do employees accept that their boss has more power than they have? Is the boss right because he or she is the boss (high power distance) or only when he or she knows the correct answer (low power distance)? Do employees do their work in a particular way because the boss wants it that way (high power distance) or because they personally believe that it is the best way to do it (low power distance)?’ (Adler, 1997, 51). In EU high power distance countries are often the former Eastern European countries, whereas for example the Nordic countries are usually considered as low power distance cultures. The third cultural dimension, uncertainty avoidance is defined by Hofstede as ‘the extent to which a society feels threatened by uncertain and ambiguous situations and tries to avoid these situations by providing greater career stability, establishing more formal rules, not tolerating deviant ideas and behaviors, and believing in absolute truths and the attainment of expertise’ (1980b, 45). As examples of cultural manifestations of this dimension, for example, in high uncertainty avoidant cultures, such as Japan, Portugal, and Greece, lifetime employment is more common. On the contrary, in such low uncertainty avoidant countries such as Singapore, Hong Kong, and Denmark, job mobility is usually relatively high. In this respect, for example, the United States then ranks quite low on uncertainty avoidance. (Adler, 1997, 51-52)

Finally, the fourth dimension, masculinity/femininity measures – in terms of masculinity - ‘the extent to which the dominant values in society are ‘‘masculine’’ – that is, assertiveness, the acquisition of money and things, and not caring for others, the quality of life, or people’, while femininity is seen as the opposite (Hofstede, 1980, 46). Therefore, masculine cultures appear as societies where ‘importance is placed on assertiveness, competitiveness, and materialism in the form of earnings and advancement, promotions and big bonuses. For the company profit counts above all, and the shareholder takes precedence over employee or customer interests’ (Schneider and Barsoux, 1997, 37). On the contrary, in feminine cultures ‘[t]he concern for quality of relationships and of work life, nurturing, and social well-being in the Nordic countries, like Sweden and Denmark, have translated into initiatives such as Quality of Work Life and extensive social welfare programs. These countries are renowned for having among the highest standards of living as well as the highest taxes’ (Schneider and Barsoux, 1997, 37). In contrast, countries such as Japan and the United States have been found to be high on masculinity.

ICT PSP Project Reporting

167

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Later, Hofstede and Bond have added a fifth dimension called Confucian dynamism, i.e. long-term vs. short-term orientation. In this dimension, ‘Long-term orientation refers to future-oriented values such as persistence and thrift, whereas short-term orientation refers to past- and present-oriented values such as respect for tradition and fulfilling social obligations’ (Kirkman et al., 2006, 286). This dimension also ‘measures employees’ devotion to the work ethic and their respect for tradition’ (Adler, 1997, 58). This dimension is mainly applicable to the Asian cultures.

Based on these dimensions, Hofstede has also calculated in his work exact indices and positions for a selected number of countries, measuring them vis-à-vis each other and placing them on the dimensional axis. These tables are readily found and usable, for example, from Hosftede’s publications and from the Internet. Therefore, these can be of help for the manager of the cross border living lab project in order to build understanding on the national cultures that are salient in his/her particular RDI project.

Other notable frameworks for national cultural recognition are those from Fons Trompenaars (1993) and from the GLOBE project (House et al., 2004). These frameworks build from the same cultural value dimension principle as the Hofstede framework. However, they take a more refined approach in terms of introducing a greater number of cultural dimensions. For example, according to Trompenaars (1993) national cultures can be distinguished according to their placement on the following dimensions: universalism/particularism, individualism/collectivism, affective/neutral cultures, specific/diffuse cultures, achievement/ascription, attitudes to time, and attitudes to the environment. On the other hand, the GLOBE project distinguishes national and leadership cultures according to the following nine dimensions: uncertainty avoidance, power distance, collectivism i: societal collectivism, collectivism ii: in-group collectivism, gender egalitarianism, assertiveness, future orientation, performance orientation, and humane orientation. The definitions for the dimensions and the respective country scores and descriptions of both the Trompenaars and the GLOBE frameworks can be found in the respective publications, yet, it can be said that they are very much akin to the original Hofstede framework. It is also notable, that these frameworks allow for national clustering. Some notable national cluster frameworks are those by Ronen and Shenkar (1985) and the more recent GLOBE clustering (Brodbeck et al., 2000). In these frameworks, countries are clustered according to their national cultural similarity. In this way, for example the Nordic countries can be found relatively similar in their national cultures, thus, forming a cultural cluster (Ronen and Shenkar, 1985; Brodbeck et al., 2000). This kind of clustering can be helpful for the project manager in recognizing national cultural features, however, it is also noteworthy that other research has found significant cultural differences between countries belonging to a particular cluster (e.g. Søderberg and Vaara, 2003). Managing cultural differences

ICT PSP Project Reporting

168

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

After identifying some of the central features of the relevant national cultures existing within the cross border living lab project network, the project manager should then decide the appropriate way of managing these differences. ‘Managing cultural differences’ here means the process(es), practices, strategies, and approaches that the project manager uses to cope with cultural differences as well as with their implications in the project network. In general, managers are said to have three basic approaches in managing cultural differences (Schneider and Barsoux, 1997). That is, managers can either ignore, minimize or utilize cultural differences and their implications. In practice, ignoring cultural differences goes against the basic advice of cross cultural management, i.e. suggests treating management and leadership practices as universal across countries. Therefore, the most viable options for the cross border living lab project manager are in minimizing or utilizing the cultural differences. It is also noteworthy that in practice, the project managers often use multiple approaches simultaneously in different parts of the project. In general, minimizing the cultural differences and their implications builds on the dual principle of either isolating the different cultures from each other or by creating an overarching project culture (Schneider and Barsoux 1997; Chevrier, 2003). In this approach, cultural differences are seen harmful and causing problems and conflicts; therefore their likelihood and existence needs to be minimized. On the contrary, the principle of utilizing the cultural differences builds on the recognition of cultural differences as a source of potential benefits, learning and innovativeness. Therefore this approach tries to build synergies out of the cultural diversity by combining the ‘best practices’ from two or more cultures.

In practice, however, Adler (1997) has described that managers have at their disposal five different strategies in managing the cultural differences: cultural dominance, accommodation, compromise, avoidance, and synergy. This is depicted in Figure 1.

ICT PSP Project Reporting

169

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Figure 1. Different strategies to manage cultural differences

According to Adler (1997) Cultural Dominance refers to the practice of ‘continuing to do things in the way of your own home culture’ (1997, 115). Usually this occurs when the managers strongly believe that theirs is the only right way to do things. Cultural Accommodation, on the other hand, refers to the opposite of cultural dominance, i.e. managers ‘attempt to imitate the practices of the host culture’ (Adler, 1997, 115). In practice this manifests the ‘When in Rome, do as the Romans do’ – maxim. Cultural Compromise occurs when managers on ‘both sides concede something in order to work more successfully with each other’ (Adler, 1997, 116). Hence, compromises and concessions are made both ways. Cultural Avoidance means a ‘choice to act as if there are no differences – to act as if no conflict exists’ (Adler, 1997, 116). This approach might in fact be a culturally contingent way, for example, in some Asian countries. Finally, Cultural Synergy refers to developing ‘new solutions to problems that respect each of the underlying cultures but differ from what would be needed in a purely domestic situation’ (Adler, 1997, 117). That is, new solutions to problems are developed based on cobining two or more cultures – solutions which differ from the cultures they spring from. These strategies can be considered to represent the ‘macro-level’ of managing cultural differences. However, it is noteworthy that on the ‘micro-level’ each of these approaches consists of managing and leadership practices and processes that should be culturally contingent, i.e. respect the relevant way of managing and leading in a particular national culture. Therefore, numerous cross cultural management guidebooks describe in more detail the managing and leading of multinational and multicultural project networks (e.g. Binder, 2007; Cleland and Gareis, 2006). In these books it is described how such ‘micro-level’ management and leadership practices as, for example, motivating, task formation, team and trust building, rewarding, and conflict management are all culturally contigent, and thus,

ICT PSP Project Reporting

170

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

have culturally approppriate ways of accomplishing them. Therefore, the task of the project manager of the cross border living lab network project is in determining and developing the culturally appropriate behavior in order to ‘maximize the benefits of cultural differences while minimizing negative effects’ (Thomas, 2008: 209). Hence, the project manager is advised first to determine the salient national cultural features of the project participants by utilizing the above described national culture frameworks, and then determine the culturally approppriate managing and leadership style. For the latter purpose, the project manager can seek advice for example from the GLOBE handbooks (House et al., 2004; Chhokar et al., 2008). 8.7 Decision categories and common decision types in cross-border living lab projects: decision typology

Based on the WP2 pilot, different kinds of decision moments and phases have been analyzed. We came to the conclusion that based on the experiences in WP2 it is very difficult to categorize decisions according to whether they are strategic, operational or managerial. This is, for example, because initially a decision might seem like an operational decision, but when time passes it suddenly turns out that it has been a very strategic decision (by hindsight) enabling/constraining, for example, other significant paths/options.

Also we came to the conclusion that it is difficult to define whether a decision is illdefined/well-defined. This is because, it might be, for example, that a decision might be initially thought to be well-defined but as time passes and new events take place/new requirements emerge/deviations occur etc. the decision might turn out have been ill-defined after all. Also in many cases, decisions are not explicitly “made” rather than they “happen” over a course of time or as a process. Therefore it is difficult to assess what is the point that we should be focusing at.

Therefore, we categorize the decisions (moments and processes) according to whether they target at 1) Planning for the anticipated project path, 2) Staying on the planned project path, and 3) Deviating from the planned project path. Below, these are tentatively elaborated for further work and edits: 1) Decisions targeting at Planning for the anticipated project path

These are decisions that set out the initial project path that is to be followed. This is the original project planning, which can be illustrated in a figure as follows: •

initial outline of the project

= a point where a decision happens

In this category decisions are made which eventually form the outline of the project progress in a linear and/or parallel fashion. ICT PSP Project Reporting

171

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

In a cross border living lab project these decision include, for example, the following: •

• • • •

Partner selection

Personnel selection

Financial decisions, budgeting

Project scope related decisions

Decision on measuring the outcomes of the project, KPIs

2) Decisions targeted at Staying on the path that was set out by the original project planning decisions

These are decisions that are taken during the project which are designed to keep the project progressing according to its initial projected path. These decisions are illustrated in a figure in the following way:

•

Decisions that fall in between the green points illustrating the original path may make a deviation but are intended to keeping to the plan eventually (they are outside of the original plan, but they are intended to enforce and ultimately lead to the realization of the original plan). Key points as planned originally can fall in this category. When moving from one green point on the path to the next, the moment to move to a new direction in the project is a decision also because it closes out possible alternative pathways and/or some part of the original path.

In a cross border living lab project these decision include, for example, the following: • • •

Decisions on moving from one project stage to another

Decisions on new personnel selections intended to enforce the original project path Technology transfer related decisions: training of the target living lab users, demonstrating the technology etc.

ICT PSP Project Reporting

172

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

3) Decisions that lead to Deviations from the planned project path, i.e. decisions leading to follow a different path than that which was set out to be followed. These are decisions that are taken when circumstances require changes to the original plan. These are illustrated in a figure in the following way:

Some decisions are initially aimed at following the path set out in the original project plan, but have consequences that make following that path impossible, and are therefore decisions to follow a different path, although this was not intended at the moment of the decision. One example in APOLLON WP2 is the June 2010 decision of Palmia to have the Xtramira device tested by an external consultancy company. The lessons learned from that test were that the capabilities of the device were insufficient and Palmia decided that a different technology was called for. Therefore, returning to the original project path did not occur, which is depicted in the figure below.

In a path flow, the decisions were: A

Decision to test technology

Path to original plan is now closed

B C E

Path closed by decision

Test and results, demonstrating shortcoming in device New path

ICT PSP Project Reporting

173

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

In a cross border living lab project, decisions falling into this category may include, for example, the following: • • • • •

Decisions on new personnel during the project Decisions on new partners

Decisions on testing alternatives

Decisions on replacing original technology with new technology Decision on a new pilot.

8.8 Other sources

In most countries intermediary organizations exist that support SMEs in international business and innovation. In the Netherlands, Syntens is a good example. Such organisations have developed checklists and guides to support SMEs that could be of use.

ICT PSP Project Reporting

174

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

9. Project Plan Development for a Cross Border Living Labs Network Contributor: Aalto University School of Economics (AAL) 9.1 Problem or requirement addressed by the Method

Project plan is the plan which is agreed among the partners of the cross border living lab project. It defines the objectives, activities, partner roles, organizational and governance arrangements, responsibilities, liabilities, profit and cost sharing, and risk management of the project. In this method template, the guidelines how to set up the project plan as well as the contents (i.e. structure and elements) of the plan are described. Project plans are used for many purposes. However, below is a list of the most common challenges that projects of any kind, regardless of the context and project type, most often encounter: • • • • • • • •

Project goals and objectives are vaguely specified

Project partners have divergent understanding on the project goals

The preferences of the partners with regards to the project are divergent and many times contradictory

The responsibilities and liabilities between the partners are vaguely specified The management structure of the project is unclear

Changes and unexpected events occur during the project and these are costly to take care of when the project is running The ways in which realized risks should be managed are vaguely defined

It is unclear as to what happens when the project is finalized and terminated

In order to make sure that these challenges are taken into account and prepared for, a project plan of the cross border living lab project is then needed. In addition to this, preparing a project plan has also many other purposes. It is used to build trust between the partners and stakeholders. It is used to increase transparency between the project participants. It can be used as a back-up in conflict situations. And it is used to build common commitment and sense of togetherness between the partners. Therefore, regardless of the cross border living lab domain, the project plan should include and take into account the following factors: Challenge area

Project plan requirement

Explanation

Ambiguous goals, objectives, expectations, prerences

Project target specification and harmonization

Project targets should be specified and harmonized between partners to ensure goal, expectation, and preferences consistency and

ICT PSP Project Reporting

175

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Responsibilities, liabilities, partner scope, risk management, deviation management

Project procedure specification and harmonization

Knowledge localization

Providing platform

transfer

Project termination

and

common

Project outcome integration, scaling

project

validation,

unambiguity

Project organization, management structure, and governance model should be defined and agreed on between the partners Cross border living lab projects require transferring of knowledge (i.e. human capital, information, technology etc. across borders) which should be organized as well as the identification of localization needs. Validation of the project outcomes in terms of their accuracy and palusibility in cross border situations, project KPIs , integration of the project outcomes to the permanent organizations of the partners, and scaling of the project outcomes should be defined

Also the point is to plan in advance. According to the conventional wisdom in project management, changes and deviations to the plans as well as adaptation to surprises increase almost exponentially in costs as the project progresses. Preparing a cross border project plan

When preparing the project plan in a cross cultural, cross border living lab context, the project manager has to bear in mind that in different national cultural environments textual documents, such as a project plan, and the ways they are paid attention to can differ significantly. In some countries project plans are developed meticulously and taken literally and as a legally binding document. In other countries, it can be seen more as a guideline, not necessarily followed to the word, but taken up as a tool for defense in conflict situations. Still in other countries, project plan might be considered as just â&#x20AC;&#x2DC;another piece of paperâ&#x20AC;&#x2122; that has to be prepared, but it is not necessarily followed at all and it is not considered to be a legally binding document in any way. For the project manager, a starting point for assessing the way the nationalities involved in the living lab project consider the project plan is the cultural value indices by Geert Hofstede. In terms of the project plan, especially the Uncertainty Avoidance is helpful. In general, it can be said that in high uncertainty avoidance countries, project plans are developed meticulously and followed to the word, and vice versa in low uncertainty avoidance countries. ICT PSP Project Reporting

176

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Another starting point is the cultural dimensions by Fons Trompenaars, and especially the Universalism â&#x20AC;&#x201C; Particularism dimension. In general, it can be said that the more universalist a country is the more project plans are paid attention to and used as a tool of project management. On the contrary, in particularist countries, business relationships are based on personal relations. Therefore, contractual documents, such as a project plan, are paid less attention to and they are not considered to be legally binding, for example, in situations of conflict, change, and deviations. For more fine-grained national cultural analysis, the framework developed by the GLOBE project by Robert House et al. offers a robust tool.

However, the living lab project manager should also bear in mind, that in addition to the national level, cultural differences exist on the level of an industry. Therefore, the project manager has to evaluate on the level of the industry of a partner country the ways that project plans are paid attention to and considered as a legal document.

As a consequence, the project manager is advised to prepare the project plan through a series of cross border project plan development sessions. These sessions should involve all the relevant partners of the cross border living lab experiment. The primary purpose of these sessions should be in determining what kind of meaning the over all project plan has for the partners, how do the partners interprete the project plan and its various elements, as well as in ensuring that the project partners have knowledge on how their interpretation of the plan might differ between one another. The steps that should be included in preparing the cross border living lab project plan are described below. 9.2 Description of the Method

In this section, the steps of preparing (i.e. building and agreeing on) and the contents of the steps (i.e. the structure and elements) of the project plan are described. Hence, a stepwise process of preparing the plan for a cross border living lab project is described in the following sections. Each section includes a table with questions and explanations to the questions. By seeking answers to the questions and writing them down accordingly should then produce the project plan as an outcome. As this is a template targeted for cross border living lab projects, it is suggested that the project manager prepares the plan in collaboration between the project partners. This is because, as mentioned above and as will be further elaborated in the next section in different cultures project plans are interpreted and paid attention to in different ways. Hence, it is important that the plan is collaboratively prepared in order for the project manager to gain understanding on how the partners interpret and use the project plan and its different elements.

ICT PSP Project Reporting

177

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Step 1. Analyzing the meaning of the project plan among the cross border project partners In the first step, the project manager should make sure how the project plan, in general, is interpreted, used, and paid attention to by the different project partners having different national cultural backgrounds.

Based on cultural anthropology, it is acknowledged that such meanings and interpretations cannot be asked directly from people representing different national cultural spheres. Therefore these issues have to be asked indirectly. Hence, the project manager should arrange joint sessions with all the cross border living lab project partners. In these sessions, building on cultural anthropology, the project manager should ask all the partners the following three questions: Question to the partner In what kinds of situations have you prepared and used a project plan before?

Which of the situations are similar and in what ways?

Which of the situations are different and in what ways?

Actions • Prepare a list of all the situations that are mentioned • Describe the main characteristics of the situations • Describe which situations a specific project partner considers to be alike • Describe the similarities • •

Describe which situations a specific project partner considers to be different Describe the differences

Purpose To enable the project manager to pinpoint the kinds of situations where the project partners are likely to take use of the project plan

To enable the project manager to understand the meaning in terms of similarity the different situations carry for a specific partner To enable the project manager to understand the meaning in terms of difference the different situations carry for a specific partner

Building on this kind of data collection, the project manager should then be able to analyze what kind of meaning the different situations where project plans have been used carry for the different partners, and especially to infer indirectly why the project plan has been used in a specific situation. This should then enable the project manager to categorize the different partners whether it will most likely a) follow the project plan to the word, b) consider it as a guideline, and use it mostly for a tool of defense, or c) not pay any particular attention to the project plan. Hence, this should enable the project manager to determine whether a specific partner places high or low in the cultural dimension of Uncertainty Avoidance, or whether a specific partner adheres to Universalist or Particularist worldview. This knowledge could then be compiled to the following table:

ICT PSP Project Reporting

178

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Meaning of project plan Follows project plan literally

High Uncertainty Avoidance Partner A Partner B Considers as a guideline and Partner X tool for defense Partner Y Does not pay any particular Partner Z attention to project plan Low Uncertainty Avoidance

Universalist Partner A Partner B Partner X Partner Y Partner Z Particularist

This kind of categorization should then provide the project manager knowledge and understanding on how the different project participants can be expected to behave throughout the living lab project in terms of their adherence to what is defined in the project plan. Step 2. Producing the general project description

In the second step, the project manager should produce a general description of the project. Its background, purpose and goal, overall timeline and budget, as well as the closing of the project should be described. In the second step the idea is to give a general overview of the project. Therefore, at this stage the description does not have to be too detailed or, for example, detailed budget can be attached as an appendix. The below table is designed to assist the project manager in writing the overview of the project. By answering to the below questions, and writing the answers down to the project plan document, therefore, should produce the project overview. Project plan item 2.1 Project background description

Questions to be answered 1. What kind of SME need/challenge does the project target at? 2. Where and how has the need/challenge emerged? 3. Who is the project initiator? 4. Who is the project client?

2.2 Project purpose description

1. 2. 3. 4. 5.

ICT PSP Project Reporting

What is the overall goal of the project? What is the purpose of the cross border aspect of the project? What is the technology involved in the project? What is the expected outcome of the project? What benefits are expected 179

Explanation This section should give an overview of the project. It should provide a general understanding on where the project originates from, what kind of need/problem it is designed to solve, and by whom the project has been started and who it is supposed to benefit. This section should give a more detailed description of the project goal and outcome. Especially the anticipated benefit of the cross border aspect in achieving the outcome should be described. Also the technology that the project addresses and the benefits of developing it in a cross border Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

2.3 Overall project timeline and budget

2.4 Project closing

2. 3. 4.

1. 2. 3. 4.

from the cross border aspect of the project? Beginning date of the project Major milestones Closing date of the project Estimated budget

What is the criteria used to determine project closing How are new knowledge, patents, business opportunities, and licensing managed during and after project closing? How are profits/losses divided between the stakeholders Who decides on the project closure?

environment should be described. In this section, an overall timeline of the project should be described. Also an overview of the major milestones that the project consists of should be described as well as the overall budget. A more detailed timeline and the project cost and finance breakdown can be attached as an appendix and will be produced in later sections. This section should describe the termination of the project. It should give an indication of the criteria used to determine when the project is closed. This can be purely a specific date or, for example, when a certain amount of knowledge, understanding etc. is gathered from the phenomena the project addresses or, for example, when a specific outcome such as certain market size has been achieved. Also an overview of the dividends and how they are divided between the project partners should be described as well as how patents, licensing, developed business models, and immaterial rights are managed between the partners during and after project termination.

Step 3. Defining project organization and scope of work

In the third step, the project manager should produce a more detailed description of the project organization, that is, the partners, the management and governance model as well as the scope of work of each partner in terms of liabilities and responsibilities. The below table is designed to assist the project manager in producing the description of the project organization and scope of work of each partner. The table begins with a template for a more detailed description of the project purpose and goals. This is needed in order to produce then a description of the organization, management and governance model, and partner scope of work, that is needed to produce the project outcomes. By answering to the below questions, and writing ICT PSP Project Reporting

180

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

the answers down to the project plan document, should produce the project organization and scope of work description. Project plan item 3.1 Detailed project description

goal

3.2 Project partner description

Questions to be answered 1. What is the goal of the project in terms of: • Technology development • Technology testing • Technology scaling • Business model development • Business channel development • Market assessment • Market definition • Market creation • Market scaling

• • • • • • • • • • •

3.3 Project partner goals

ICT PSP Project Reporting

• • • •

Who are the principal partners of the project? SME Home country Living Lab Host country Living Lab Other involved companies Involved public institutions/organizations Funders, financiers Banks Insurance companies Sponsors User communities Consultants

What are the goals of the partners in the project? Technological goals Business goals Market goals Financial goals

181

Explanation This section should give a more detailed description of the project goal(s). The cross border living lab project can have multiple goals or just one. The list in the adjacent column is intended as a checklist. The project manager should consider the project goal(s) at least in terms of the items in the list and describe what is/are the project’s primary goal(s). As this template is to be used in cross border projects, the project manager should especially describe the goals and benefits that are targeted to be produced by the cross border aspects of the project. This section should give an understanding of the partners in the cross border living lab project. It is advised to describe briefly at least the following aspect of each partner: • Name and background of the partner • Year of establishment • Turnover (if applicable) • Business idea (if applicable) • Expertise • Overall role(s) in the project In order to produce this description, the project manager most likely will have to go through a series of sessions with each partner for coming up with an understanding on how the partners perceive their goals for the project. However, although laborious, this is crucial as the goals between the partners may be highly divergent. Therefore, coming up with this information should Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

3.4 Partner responsibilities and liabilities (= scope management)

1. •

•

3.5 Project management organization and governance model

ICT PSP Project Reporting

Who is responsible for what? Project process aspects (What is each partner supposed to do in the project and what it is responsible for?) Social aspects (What kind of relationships of one partner to another are required by the successful delivery of the project?) Technological aspects (What kind of knowledge, technology and/or skills and resources each partner brings to the project?) Economic aspects (What kind of funds a partner brings into the project/costs are incurred to a partner during the project?) Legal aspects (What are the responsibilities and liabilities of a partner bound by the project contract?)

What is the organizational structure of the project? a. What is the project supervisory board composition? b. Who is the project manager? c. Who are the monitoring parties of the project? d. What is the primary way of settling disagreements? e. What is the court for settling disputes?

182

be regarded as an act of creating a sense of togetherness between the partners. This description is crucial, as the scope is often a source of serious conflicts between the project partners during the project execution. Often the definition of the project scope per partner is also something that has to be revisited several times during the project. This is because changes and unexpected events inevitably take place during the project. In order to come up with this description and answering the questions in the adjacent column, the project manager should go through a series of negotiations between the partners. This is because basically scope management is about the division of profits, costs, risks, and responsibilities. This is made challenging as in cross border living lab projects, national cultural differences affect these negotiations. However, multiple guidebooks are available on the market, which describe in detail the tactics and processes of negotiating in a multicultural setting. This description will most likely involve multiple rounds of negotiations, as the project management and governance model is a strategic question for the project and for the partners. However, in order to provide this description the project manager should describe: • project organization chart based on the above described project responsibilities • project supervisory board members and their responsibilities • project manager’s Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines • • • • •

Step 4. Developing project work breakdown structure

responsibilities project monitoring parties and their responsibilities responsible persons/parties in case of changes/deviations responsibilities of each partner in case of change/deviation primary ways of settling disputes court for settling disputes

In the fourth step the project manager should develop the detailed work breakdown structure. In this description it is advised that the project manager takes into use the well established project management tools for work breakdown description such as WBSs and GANTT and PERT charts. Professional software is available for developing the work breakdown structure. The outcome of using these software, i.e. the actual work breakdown structure should be included as an appendix in the project plan document. The basic principle of producing the work breakdown structure is to describe in detail each activity and task for each of the project partners in yearly, monthly, and weekly basis for the duration of the whole cross border living lab project. It should include the beginning and end dates of each activity and task per project partner. It should also describe all the project milestones and their dates for determining whether or not the project is progressing as planned. Of major importance are the relationships in terms of sequencing and overlaps of each activity and task. This gives the project manager a detailed overview of the project progress and the organizational and technical requirements needed in order to produce the activities and tasks of the project. Finally, the work breakdown structure is necessary for the project manager in determining the human and financial resources needed in the different stages as well as for every activity and task of the project. As a result the project manager should produce a detailed description of the activities and tasks involved in the four general phases and their component activities in a cross border living lab project as described in the table below: Cross border living lab phase

Component activity

4.1 Connect: In this phase activities such as setting up Living Lab network, identifying stakeholders, creating work plans and vision, determine the scope of the collaboration, project owner, defining technical platforms, funding and contracts are carried out. ICT PSP Project Reporting

a) b) c) d) e) f) g)

183

Business opportunity identification Stakeholder identification Project vision and scope determination Project owner identification Definition of technical infrastructure Ensuring funding Preliminary analysis of business model Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines 4.2 Plan and Engage: In this phase activities such as identifying partners, identifying risks and drivers in the cross-border project, create management plan / analyze stakeholders, train cross-border partners, define technical and IPR issues, ensure project team commitment are carried out.

4.3 Support and govern: In this phase activities such as managing stakeholder, selecting research methods, planning financial aspects, implementing technical infrastructure, supporting deployment, designing evaluation frameworks, designing operational model are carried out.

4.4 Manage and track: In this phase activities such as assessing impact, revising operational mode planning business model, evaluating usage of technical platforms and handover of responsibilities for new pilot are carried out.

a) Identification and selection of partners b) Collecting business needs of cross-border innovation c) Identification of cross border project risks and benefits d) Building consortium and establishing roles e) Agreements and contracts f) Identification of IPR issues, IPR handling g) Business modeling h) Createing collaboration environment i) Planning product / service testing j) Value network analysis

a) Project management & governance b) Experimental testing of products and services c) Managing user groups d) Benchmark testing results e) Management of stakeholder interests f) Market and business analysis g) Business plan development h) Support collaboration of SME and living labs i) Knowledge sharing & management j) Management of value networks for open innovation a) b) c) d) e)

Defining lessons learned and best practices Preparing commercialisation plans Business plan development Project termination planning Knowledge sharing & management

Step 5. Defining project monitoring and evaluation practices and measures In the fifth step, the project manager should produce a detailed description of how the project, its process, and outcomes are to be evaluated and measured. The most common way to evaluate the project is to operationalize and measure the outcome in terms of time, cost, and quality. These are the worldwide standard criteria used in project evaluation.

However, when developing the description on how the project, its process, and outcomes are to be evaluated and measured, the project manager should be aware of two salient challenges: Firstly, evaluating the project in terms of time, cost, and quality is subjective. This does not simply mean that the indicators used in evaluation and measurement would necessarily be subjective. Rather, the point here is that evaluating and measuring the project is dependent on the viewpoint. The living lab, the SME, and, for example, the governmental institutions engaged in the cross border living lab project are all bound to have their own perspectives to what ICT PSP Project Reporting

184

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

is considered a success (or a failure). These perspectives may both converge and diverge for certain points.

Secondly, existing research on cross cultural management has found out that perceptions in relation to monitoring the project progress are culturally dependent. This means that in different (national) cultures the ways in which the project progress in relation to the plans are paid attention to in different ways. In Geert Hofstede’s dimensional framework this can be seen to relate to the cultural dimension of Uncertainty Avoidance (UA). Hence, in high UA countries the project progress is measured tightly in relation to the plan, hence, in those countries the basic assumption is that every single step described in the plan should be completed and complied with. In low UA countries, however the situation can be reversed, as in those countries it can be the overall milestones or project goals that are the priority. Consequently, in these countries it is considered sufficient as long as the overall milestones and project goals become fulfilled, regardless of whether or not every step described in the plan are carried out to the letter. As before, this aspect is also dependent on the industry cultures in addition to national cultures. Because of these two challenges, it is advised that the project manager develops the description of the project monitoring and evaluation practices through a series of sessions held together with the project participants in order to come up with a satisfactory level of convergence in the views regarding how the project, its process, and outcomes are to be evaluated and measured. Building on these sessions the project manager should then produce a description that aims at answering the questions in the below table: Project plan item 5.1 Criteria for evaluating activities and tasks of the project partners

Questions to be answered 1. Time: how is the timeframe of an activity/task evaluated? 2. Cost: what are the payment criteria for an activity/task? 3. Quality: what are the quality criteria of an activity/task?

Explanation It is beneficial for the project manager to decide on the criteria and ways to measure in some ‘objective’ manner when a particular activity or task in the project is ‘in time’ and when it is ‘delayed’. Projects often consist of payments to the different project partners during the project process. Therefore the criteria used in evaluating whether the activities, tasks and milestones have been met in a satisfactory way should be defined so that the payments can be made. The criteria for evaluating the quality of each activity/task needs to be defined, so that it

ICT PSP Project Reporting

185

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

5.2 Project monitoring activities and their organizing

1. a)

c) d) 2. a) b) c)

d) 3. a)

b) c)

d) 4.

5.3 Project outcome evaluation

ICT PSP Project Reporting

How is the project monitoring organized and controlled? Who is the person in charge of monitoring? To whom does this person respond to? Who are the auditors? How is achieving milestones checked?

How are project monitoring activities performed? When are they arranged? Who is responsible for arrangement? Who are the reporting parties? Who are the parties to be reported to? What are the procedures for project scope and plan revisions How often are the revisions done? Who is the responsible party? How are the revisions evaluated? Who is the responsible decision maker accepting the revisions?

How are deviations verified by project monitoring handled? a) What is the compensation and sanction plan between the partners in case of deviations? b) What is the primary way of settling disputes? c) What is the court where the disputes are settled? 1. What are the key performance indicators of the project in terms of 186

can be evaluated whether the task/activity meets the required quality standards/specifications. The monitoring of the project progress and its organizing needs to be defined. The parties responsible for monitoring the project needs to be defined as well as how often monitoring will take place. The parties to whom the monitoring will be reported also need to be defined.

In every project there are deviations from plans, i.e. changes, surprises, revisions of the project plan during its course etc. Therefore, the procedures and organization for taking care of these deviations needs to be defined. It is also not uncommon that conflicts occur between the partners during the project progress. Therefore, it is of utmost importance to define how conflicts are handled during and after the project.

Defining the key performance indicators in terms of the items listed in the previous column Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines a) b) c) d) e) f) g) 2.

a) b) c)

d) e)

Time Cost Quality Technology Monetary Market Partner

How are the cross border benefits measured? Cross border RDI benefits Cross border technical benefits Cross border market benefits Cross border client benefits Cross border financial benefits

Step 6. Defining detailed project budget

can be a project of its own. However, this is vital in order to evaluate whether the project, upon its closing, has been a success or a failure. It is advised that the project manager defines these criteria together with the key partners of the project in order to cope with the subjectivities and cultural challenges involved in this definition (as described in the introduction to Step 5.) As this is a project plan template for a cross border living lab project, the evaluation criteria for the benefits from the cross border aspect of the project needs definition. Usually these are related to the areas listed in the previous column. More specifically, in these projects, cross border benefits are often sought after in terms of benefitting from cross border RDI in different cultural settings; tapping into different technologies and clients offered by different national business systems; and tapping into the scaling possibilities offered by different national markets.

The sixth step of producing the project plan, i.e. defining the detailed budget and cost structure to the project builds heavily on Step 4. Developing project work breakdown structure. Hence, in the sixth step, the project manager should take the project work breakdown structure as a basis, and collect from each project partner their estimates on the costs of each task and activity. This will most likely be a balancing act and require negotiations between the project partners as often there are parties included that have motives for selling their input as expensively as possible, and vice versa, there are often parties with motives to purchase othersâ&#x20AC;&#x2122; inputs as cheaply as possible. In order to produce the detailed project budget, the project manager should seek answers to the following items:

ICT PSP Project Reporting

187

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Project plan item

Questions to be answered

Explanation

6.1 Cost estimation and budgeting

For addressing these questions, the project manager needs the project work breakdown structure and the cost estimates of each task/activity from each partner. Matching the project work breakdown structure and cost estimates then helps the project manager to take into account that many project activities can take place simultaneously and overlap. Therefore it is of utmost importance to compile the cost estimates, in addition to per activity/task, also on a monthly and yearly basis. It is also helpful to compile them according to the cross border living lab project life cycle phase in order to see how much each phase is predicted to cost. Cost control and monitoring is a vital part of every project. Therefore, the project manager should describe the responsible parties of cost management in each partner, so that the responsibilities of cost related financial flows between the partners are defined, clear, and agreed on. As deviations take place during the project, these can often mean cost overruns. Managing cost overruns is therefore an integral part of projects. This is especially an important part to decide and define in cross border projects where different laws and divergent interpretations of those laws exist. This also boils down to the need to define the project milestones and activity/task targets, in order to be able to measure whether or not a deviation has taken place, and whether or not cost overruns are occurring.

6.2 Cost monitoring

a. b. c.

What is the cumulative cost estimate according to the project life cycle phase (Connect; Plan and Engage; Support and Govern; Manage and Track)?

Who are the parties responsible for cost monitoring in each partner? Who are the accountants? Who are the persons in charge of approving the incurred costs and budget changes?

a. b.

6.3 Managing cost overruns

1. a.

b. c.

ICT PSP Project Reporting

What is the project cost estimate and total budget? Per activity/task Monthly Yearly

What are the ways of managing cost overruns? What is the compensation and sanction plan between the partners in case of cost overruns? What is the primary way of settling disputes? What is the court where the disputes are settled?

188

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Step 7. Describing the project human resource management and communication plan In a cross border living lab project, describing the project human resource management and communication plan is perhaps the most challenging part. This is because the existence of national cultural differences between the project partners. There are hundreds of studies and guidebooks on the market on how cultural differences affect projects and how they should be managed. These describe the myriad of ways that national cultural differences enter and affect the project. These effects should also be taken into account on a general level when describing the project human resource management and communication plan. In order to describe the project human resources management and communication plan, the project manager should seek answers to the following items: Project plan item 7.1 Personnel requirements

Questions to be answered 1. What is the required amount of personnel in each partner? a. Monthly b. Yearly c. Cumulatively according to project phase (Connect; Plan and Engage; Support and Govern; Manage and Track)

7.2 Managing cultural differences

1. a.

b. c. d.

ICT PSP Project Reporting

What is the general plan to manage national cultural differences in the project? How are national cultural differences discovered? When and how are cultural differences to be ignored either by cultural dominance or accommodation? When and how are cultural differences to be minimized by creating an overarching experiment culture? When and how are cultural differences to be utilized by creating cultural synergy 189

Explanation This section should build on the project work breakdown structure and the cost estimates. That is, the amount of personnel should meet the work breakdown targets as well as fit the budget. Compiling lists of personnel requirements from each partner in relation to each task/activity on a monthly/yearly basis will help the project manager to observe the simultaneity and overlap of the tasks and personnel demands. Accordingly it is advised to estimate and describe the overall personnel requirements cumulatively according to the cross border living lab project phase. In recognizing cultural differences in a cross border project, the most often occurring ways are arranging series of sessions led by a multicultural consultant and/or engaging the project personnel to cross cultural training sessions. Taking into consideration these options should be estimated and described in this section. In general, the most common ways to manage national cultural differences in cross border projects is either to ignore, minimize or try to utilize them. Often a mixture of these basic approaches is used.

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines out of national cultural diversity?

Although it might not be beneficial to try and describe in detail how these approaches will be used, it is however beneficial for the project manager to anticipate them on a general level by considering the answers to the questions in the adjacent column. In the adjacent column, cultural dominance refers to the imposition of the ways of working of one cultural group to the others.

7.3 Project communication

1. a.

b. c.

What is the project communication plan? Project communication and information distribution between the partners Reporting Meetings

In the adjacent column, cultural accommodation refers to the adaptation of one cultural group to the ways of another cultural group. When describing the project communication plan, the project manager should seek answers to the following questions: In what kind of format(s) is communication to be taken care of? How often should it take place? What should be reported to and by the project partners? What kinds of meetings should be arranged (progress review meetings, planning meetings, change implementation meetings) and how often? Where should the face-to-face meetings take place? Who are the responsible persons for arranging the meetings and preparing the agendas?

Step 8. Describing the project risk management plan

The eighth and final step of producing a project plan for the cross border living lab project is describing the risk management plan. Risk management is a special and truly vital part of cross border living lab projects. As shown by common experience and hundreds of academic studies on project management, deviations and surprises are an â&#x20AC;&#x2DC;order of the dayâ&#x20AC;&#x2122; in any kinds of projects. Cross border living lab projects are not an exception to this rule. Changes inevitably take place, deviations from plans (both conscious and unintended) happen, surprises occur. Unfortunately, many of these tend to introduce challenges and hazards to the project progress, that is, they give rise to realization of risks. Therefore, the project manager should take this into account and describe a risk management plan in the overall project plan description.

For identification and measuring of risks, there are professional software and tools available on the market. The project manager of the cross border living lab project is ICT PSP Project Reporting

190

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

advised to use these. The outcomes of these risk identification and measuring tools should be included as attachments in the project plan. In addition to this, the below template is intended for the project manager to be used in describing the overall plan for risk management in the cross border living lab project. Project plan item

8.1 Overall risk management principle

Questions to be answered 1. a.

8.2. Risk identification and measurement

1. a.

b. c.

a. b. c. d. e. f. g. h. i. 3. a. ICT PSP Project Reporting

What is the overall risk management principle? Risks are borne by the partner best equipped to manage them Risks are borne by the partner deemed liable for inflicting risk exposure Risks are identified ex ante and they are borne by an ex ante named partner

What is the process of identifying risks? What risk management and identification tool is used? How are risks identified objectively (quantitative)? How are risks identified subjectively based on earlier experience (qualitative)? What are the identified risks (known unknowns)? Technological risks Market risks Legal risks Project organizational risks Project stakeholder and network risks Political risks National cultural risks Institutional risks Environmental risks What are the probabilities to identified risks? Objective probability assignment 191

Explanation

In this section the project manager should describe the overall principle of risk management used in the cross border living lab project. As this is an area that is likely to inflict major conflicts between the partners if considered during the project progress when some risks have been realized, it is best to decide on this principle before the actual project execution. As this is about deciding on a highly salient project management principle, that touches every participant, it is advised that the project manager decides on this principle only after careful discussions and negotiations between the project partners. This section is best advised to be produced by taking advantage of the project management software and tools that are available on the market. However, the overall purpose of this section is to produce the general risk management plan. That is, the process of identifying the risks should be described. This should include the identification of both ‘known’ unknowns as well as ‘unknown’ unknowns (those that could be anticipated to be a source of risks but nevertheless highly equivocal). Building on this, the actual description of identified risks should then be produced. This should be followed by assigning each risk with a probability of occurrence. It is noteworthy that the probability assignment consists of both objective and subjective Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines b. 4. a. b. 5.

a. b. c. d. e.

f. g. h. i.

8.3 Risk plan

management

a. b. c. d. 1. a. b. c.

2. a.

ICT PSP Project Reporting

(quantitative) Subjective probability assignment (qualitative)

How are probable sources of unexpected events (unknown unknowns) identified? How are the objective sources of unexpected events identified (quantitative)? How are the subjective sources of unexpected events identified (qualitative)?

probabilities. Finally, contingencies, i.e. provisions, to each identified risk should be assigned in order to be prepared if a risk actually realizes during the project progress

What are the probable sources of unexpected events? Technology Market Legal Project organization Experiment stakeholders and network Political National culture Institutional Environmental

What are the contingencies to each identified risks as a function of risk probability? Monetary contingencies Human resource contingencies Organizational contingencies Sanctions between experiment partners/stakeholders What is the formal process of managing risks? Responsible parties Responsible persons Action sequence in an event of occurring risk What is the plan for settling disagreements in risk management? What is the primary way of settling disagreements? What is the court where disagreements are settled?

192

As before, the actual process of managing the risks should also be described in the project plan. This should include the specification of who are the responsible parties for risk management in each partner, and more specifically, who are the responsible persons. A general description of the action sequence in case of a risk occurrence should also be described. This is important as research has shown that perception to risks and the actual management of risks is culturally contingent. Therefore it is beneficial for the project Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines manager to discuss in advance with the project partners how they perceive risks and their management in order to produce a sufficiently shared understanding and agreement on this process. Finally, the ways of settling the disagreements in relation to managing realized risks should be decided and described.

9.3 Implementation of the Method The detailed project plan should be produced at the beginning of the Plan and Engage Phase of the cross border Living Lab project. It should be done in cooperation with the key partners of the project, i.e. the target country Living Lab, the SME, the target country client(s), and key institutional authorities in the home (consider innovation/technology export permissions) and target countries. The Project Manager/Owner and the possible Steering Group Head should be in charge of developing the project plan. The project plan should be disseminated to all relevant parties.

ICT PSP Project Reporting

193

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

10.

Cross-Border Knowledge Sharing

Contributor: LTU-CDT

10.1

Objective of the method

This method support the exchange of best-practices from local and cross-border pilots on user-behavioural changes mechanisms and measurements. Partners will document and share their experiences in measuring behavioural changes among end-users when experimenting with new ICT solutions. 10.2

Method description

A short summary of the suggested process:

A presentation for sharing knowledge on experiences of methods for behavioural changes. A template will be provided to make sure all report experiences in the same format. 2. Use local pilot experiments as expert knowledge exchange cases to try and share approach and methods. These cases will also be discussed and analysed jointly during the process as well as in a workshop. 3. Carry out two workshops. i. In the first workshop different partners describe their cases and their experiences. The first workshop end with the a summary and decisions for further steps to be taken towards the creation of an unified view of the topic being under development in the knowledge sharing process. 1. Each presenter has 15 minutes for presentation of their best cases 2. Best Case presentation from all partners 3. Joint Discussions on the topic. Each presenter brings two questions to discuss, e. g. a methodological issue you need support and help with. 4. The joint discussion should be closed with each partner having decided to use a some of the experiences gained from the other partners. The experiences from this will be presented and evaluated in the next workshop ii. In the second workshop, a new template for describing the knowledge sharing topic is distributed among the partners in the boundary crossing project. Describe the following: 1. Case process 2. Technological support in case (for studying and measuring) 3. Methods in case 4. Which questions the case was focusing on and why these questions were relevant 5. Users that were involved in the case 6. Lessons learned from the case 7. Identifyed KPIs in the case, how you measured the success of the case

Technology involved: For exchanging experiences from local experiments for measuring and follow up a wiki is suggested to be used. ICT PSP Project Reporting

194

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

10.3

Deployment plan

As part of the knowledge sharing across borders, each participating partner should use a local case which all have the same overarching focus, for example, user behavior change of energy consumption by means of energy visualisation.

In order to make it possible to share knowledge across borders, some parts of these cases should be designed in similar manners. Make sure that the following aspects are covered in the description of the case: 1. Technology description â&#x20AC;&#x201C; describe the technology to be implemented

2. User involvement â&#x20AC;&#x201C; describe the users, how many and where they are situated 3. Identify selection criterions 4. Define case duration time

5. Divide roles and define responsibility areas

6. Describe the aim of the case on an overarching level.

ICT PSP Project Reporting

195

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

11.

Observation Data Collection and Focus Groups

Contributor: UP8 / Lutin User Lab 11.1

Problem or requirement addressed by the Method

Sharing and comparing technologies/methodologies in order to understand to what extent local results can be extended to other contexts and which common technology or methodology can be built for generalization. 11.2

Description of the Method

The method consists of a combination of quantitative and qualitative research methods. In particular, it applies a contextual approach as it builds on data that was gathered through transaction data logging, observations using a semi‐structured observation protocol, and by means of focus group interviews via a semi-‐structured interview guide. 11.3

Use of the Method

Within the framework of the Apollon project IBBT-SMIT conducted research into the impact of the mobile game application that was developed within the project on the museum experience of young museum visitors. The game application is the result of a close cooperation between IBBT-iLab.o (who delivered the MuseUs technology) and the French cross media production company Virdual (who provided the 3D technology), in close consultation with the Antwerp museum of contemporary art “Museum van Hedendaagse Kunst Antwerpen” (M HKA, Belgium; who provided the content), the latter both small and medium enterprises participating in the Apollon project. In close consultation with M HKA staff members, IBBT-SMIT researchers facilitated the implementation and user assessment of the game on site. The primary aim of this research consisted of examining the experiences and practices related to the application’s use. In particular, we intended to assess the impact of a game on visitor’s movements, art‐viewing habits, interaction patterns, learning behaviour, etc. In a wider perspective, this research explores the impact and added value of 3D game applications on museum perceptions and experiences in a museum setting. 11.4

Implementation of the Method

1) Transaction Log Analysis

All user activity within the game application was automatically logged. Transaction log analysis is a well-established method in various information sciences, which comprises the study of “electronically recorded interactions between online information retrieval systems and the persons who search for information found in those systems” (Peters, 1993; cited in Jansen, Taksa and Spink, 2009). It enables both the analysis of aggregate user data and individual patterns. The data in this study was collected during three user sessions, each logging session comprising ICT PSP Project Reporting

196

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

approximately 1 hour. User activities were time stamped and include: (1) scanned work of art per time use per participant, (2) the number of times a piece of art was matched to an assignment and (3) the number of times an art work was scanned as favourite work. 2) Observation

We opted to gather specific use and game experience data by means of observation, an established and standardised method to collect data in diverse qualitative research designs. By means of a pre-‐ designed semi-‐structured observation protocol, IBBT-‐SMIT researchers observed the participant groups while they were briefed and engaged in the game assignment. In particular, the researchers assumed the social role of “observer-‐as-‐participant”, an observational role in which the observation activities are explicitly made knowable to all participants. The recorded data served as input during the subsequent focus group interviews, and was carefully considered as triangulation technique. The observational protocol was subdivided into three separate chunks aimed at mapping use and, to some extent, usability concerns, yet with a particular interest in the impact on overall game and museum experience. At the time of briefing the participants, the following items were observed: • •

• • • • •

• •

Do the participants ask any questions? If so, about what aspects do they have questions?

Is there any interaction between the participants at this point? Which kind of interaction?  In the course of the gameplay, the following points were mapped:

Do the participants get to work easily? Was the game explanation clear enough? If they have any questions at the start of the game, what are they about? Are the participants questioning themselves? Does the game seem clear? How long does it take before the first QR code is scanned?

How do the participants interact: do they discuss the game with other participants? Do they  talk about other issues?

Which reactions prevail during the gameplay? Are they positive/negative? Are there participants that defect? Which game components receive positive evaluations during the gameplay? Which game components receive negative evaluations during the gameplay? Are there any signs of frustration? When? Do the participants move alone, in twos or in a group? Is the game played individually?

Are the participants immersed in the game? Are they having fun? At what time during the observation do they appear distracted?

On the level of the museum experience, the following matters were observed: ICT PSP Project Reporting

197

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • • •

How do the participants move around the museum? Which route do they take? Do they halt at art pieces?

Do the participants take in the pieces of art in any other way, in comparison with the ‘regular’ (non-‐participating) visitors that are present? Do the participants seem more involved with the art pieces? Do they consciously handle the exposition? Are the participants particularly focused on executing the assignment? Do they see anything else inside the museum?

To which extent do they seek help from museum staff members, other visitors or peers?

3) Focus group interviews

To gather in-depth qualitative data in order to examine game use and overall game experience, three focus group interviews were organised. In each focus group, the youngsters were interviewed by means of a semi-structured interview protocol about their experience while playing the game, the application’s accessibility and use, the educational game component and its broad-spectrum added value, and at the end, they were invited to give general user feedback. The interview guide was semi-‐structured, rather than structured, allowing new questions to be raised during the interview as a result of the interview course.

The three focus group interviews were audio recorded and subsequently transcribed by means of “Express Scribe”, professional audio player software designed to assist the transcription of audio recordings. Based on the transcriptions, the author then coded the data in order to generate categories for coding and analysing data. A significant remark on the methodology is the social desirability bias as the M HKA museum itself served as location for the interviews and a museum staff member (i.e., an apprentice) was present during the interviews. We attended to this concern during the three focus groups, a.o., by presenting the focus group as a learning opportunity for both the university researchers and museum staff and by emphasizing the importance and value of a scrupulous attitude for the further continuation and development of the research. 4) Survey research

To obtain quantitative data on the living lab experiments, we have presented subjects with a survey that they were asked to fill out after their usage of the prototype. In this survey, we gathered three types of data: 1. Demographic data: like age, gender, etc...

2. Business model-related data: which allow us to find out for example how much a user would be prepared to pay for the final version of the app.

ICT PSP Project Reporting

198

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

3. Functional performance of the prototype: for this, we based ourselves on the Pervasive Game Flow model (http://dl.acm.org/citation.cfm?id=1236238). The 8 components (e.g. concentration, usability, ...) of the model were polled by asking two types of questions : a. How did the prototype do regarding the component in question?

b. How relevant did the respondent find the component in question?

4. This approach allows us to identify the components that the user sees as important and how the software performed on these components of the model. Such analysis can guide us in the approach we select for improving the prototype in the next development iteration.

ICT PSP Project Reporting

199

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

12.

Collaboration and Communication Tools

12.1

Problem

In order to set up, plan and eventually operate a cross-border living labs network, collaboration and communication among different partners in different locations is critical. Partners include living labs, SMEs, larger companies, local stakeholders and innovation intermediaries. Collaboration and communication needs for such situations can be very diverse in terms of time and place. Partners may be located at the same location, or are working on a distance, or mobile. They may need to interact at the same time (synchronous) or at different times (asynchronous). Sometimes a schedule of meetings, face to face or remote, facilitates regular interactions. Place

Same location

Different location

Time

Same

• • • •

Different

•

Face-to-face meetings Smartboards Electronic meeting room Group brainstorm, problem solving Team rooms

(Source: Grudin)

• • • • •

Video-, audioconferencing, Chat, Skype Application sharing Shared workspace E-mail Social software (Web 2.0)

International partners who collaborate remotely in a project need tools to keep up communication, since they can’t regularly communicate in person. Communication needs to be established for the project overall, as well as between technical, business and administrative personnel.

Efficient and effective collaboration and communication is important during all the phases of a project. Issues to be addressed by collaboration and communication tools include, for example, keeping partners up to date on project deployment, detect, discuss and solve issues/problems, and maintaining a process of scheduling & monitoring. These tools are required to be easily accessible by everyone involved in the experiment. They should be flexible enough to suit groups of people, since many different partners are involved in the experiment. There has to be a set of different tools to enable different ways of communicating, if one tool is capable of serving all ways of communication that would be enough, too. 12.2

Method / tools description

Collaboration and communication tools can be used throughout a project cycle. They connect partners working remotely on a regular basis and facilitate teamwork on a distance. ICT PSP Project Reporting

200

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

It is suitable to use a set of tools to cover different aspects of communication such as regular updates, troubleshooting, scheduling & monitoring. In the beginning of the project an initial set of tools should be agreed on as well as a schedule for regular updates.

A shared workspace enables partners to share and co-author documents, exchange messages, engage in synchronous conferences. Mainstream tools are offered by IBM (Notes, SameTime, WebSphere), SAP (Netweaver), Microsoft (SharePoint). Within Apollon, the MyBBT system is used. Many organizations across the world are using BSCW. An increasingly important class of tools is indicated with Web 2.0 (social networking).

Cross border living labs networks will benefit from using collaborative working environments and social networking software. Different pilot challenges may need different functionalities. A document repository (like BSCW, or the system used for myBBT) will be a useful first step. The BSCW system explored in Ecospace has extended facilities for presence management, conferencing, project management and other. 12.3

Sources

New Global (global working environments), MOSAIC (mobile and collaborative working), Ecospace (eProfessionals Collaborative Workspaces), Ecolead (collaborative networked organizations) and many other EU projects. Many literature articles are available. See also: http://en.wikipedia.org/wiki/Collaborative_software.

The ECOSPACE Integrated Project (2010) has developed a comprehensive set of collaboration tools, using the basic platform of BSCW, allowing also the integration of existing tools, to support professional communities.

Ecospace is one of the projects that have produced an elaborate state of the art description of collaboration tools. There are a myriad of software tools to support online collaboration. Knowledge workers have real-time conferencing tools at their disposal, as well as collaborative authoring tools, workspace functionality, messaging support, functions to coordinate the collaboration, awareness information about the people they collaborate with, facilities for persistent conversations and functionality to syndicate contributions. Figure below, which is an updated version of the figure by Oâ&#x20AC;&#x2122;Kelly & Gotta (2006), illustrates the key functionalities of communication and collaboration infrastructure.

ICT PSP Project Reporting

201

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Ecospace (2007), update from O’Kelly & Gotta (2006).

12.4

Experiences from Apollon pilots

The tools in use may vary, but we recommend following basic tools: • • • •

Online conferencing tool to suit multiple callers and visual context (such as Adobeconnect) A platform for document sharing (see above for suggestions) Conference call tool (such as Skype) Minute template.

It needs to be made clear to all participants, what tools are in use and to what extent they are used. There are plenty of common tools available. In the eManufacturing Work Package environment several tools have been in use, some of them provided by one of the project partners. During the experiment further methods have been introduced to enhance communication. It was decided between partners which tool to keep and which would not be of use for them. The set of communication tools proved to support the experiment essentially.

From the beginning of the experiment several different tools for communication have been in use in WP4. Further tools have been discussed and added. The value of these tools has been checked throughout the experiment in order to continuously improve communication. ICT PSP Project Reporting

202

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

List of tools: • • •

• • • • • •

Bi/weekly conference calls – used to keep project partners in different locations up to date Documentation sharing e.g. BSCW, Google Docs.

SAPconnect collaboration tool – this conferencing tool can be used to share the hosts screen with everyone else while simultaneously hosting a phone conference, it supports interactivity between all partners using it IBBT platform for document sharing, minutes etc. – the platform is used for storing documents and minutes for all other partners to be viewed and edited

Skype conferencing – Skype is a tool used for internet-based video/conferencing worldwide

SAPmats for downloads – this tool helps upload/download larger files conveniently Minute template – a template was adapted for minutes from calls Weekly coordination meetings between local stakeholders

LinkedIn – this tool was added later and after using it partners concluded it does not suit the purpose they had been looking for

These communication tools are used throughout the experiment during all phases of the Living Lab networking lifecycle.

ICT PSP Project Reporting

203

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

13.

Project Meeting

13.1

Problem

Collaboration in a network of living labs, or in setting up a network, requires project meetings. For example when a service/product is offered in a different country remotely, the following sessions will be needed: • • • • •

Introducing a product to the customer

Introducing the project to the partners including conceptions, possible obstacles and activities Motivation: Connecting provider and customer in order to get to know each other and build trust Clarify project goals: introduce schedule including milestones Room for initial discussions of the core team

There is a need for a “script” to prepare, organize and support such meetings. This section elaborates the project kick-off meeting. 13.2

Method

The Kick Off workshop is used during the Plan & Engage phase of the experiment. Its goals are to connect partners and introduce technology. It is prepared early on before the implementation of the product, it is suitable to carry out the workshop on-site at either the product provider or customer factory. To meet the described requirements all involved partners should be present for the workshop. Topics for the workshop include: • •

• •

Introduction of partners, motivation for the project

Project introduction/demonstration including project scheduling to be prepared by the project lead

Technical introduction/demonstration to be prepared by the technology provider(s) Tour of the factory

13.3

Example: project kick-off workshop

A date and place for the workshop has to be set early during the Connect & Engage Phase. The technology/product provider has to prepare a technical introduction or demonstration. The partner hosting the meeting has to prepare a factory tour.

Additionally the customer could prepare an introduction to its factory/product. In Work package 4 context this method was used in the beginning of the implementation of the first use case at the FIAPAL Living Lab environment. The goals of the workshop were: ICT PSP Project Reporting

204

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • •

Getting to know each other

Demonstration of the MDI platform

Running an initial training session with the MDI platform Tour of the Future Factory Living Lab.

The Workshop was planned and carried out by the team at the Future Factory Living Lab supported by the Work Package 1 liaison.

The Work Package 4 partners agreed that the kick off workshop was an adequate tool to get to know each other and build trust among project partners as well as securing all partners had equal levels of information and dedication.

The kick off workshop took place during the Plan & Engage phase of the experiment.

ICT PSP Project Reporting

205

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

14.

Cross-Border Application Development Framework

Contributor: UP8 14.1

Problem or requirement addressed by the Method

Guidelines to set-up cross border experimentation in the future. 14.2

Description of the Method

The aim of this method is to overcome the typical problems that arise when distributed teams develop [an] application[s] together: • • •

how to share source code, assets and resources

how to setup an automated and swift build process when dealing with different technologies

how to execute technical project management: issue tracking, progress tracking and release cycle scheduling

14.3

Use of the Method

This method should be used by the technical lead of [a] distributed team[s] to provide his developers with a set of tools, methodologies and specifications that will facilitate cross-border application development and technical project management.

14.4

Implementation of the Method

The method consists of a number of tools, best practices and recommendations. a. Collaborative project management service (CPMS)

A CPMS provides you with an integrated set of online services that facilitate distributed application development. The amount and type of provided services differ wildly on the various CPMS providers 11, but typically include issue tracking and/or VCS (see b) hosting. One can use several CPMS providers for assorted services, but one of the real benefits of a CPMS with a plethora of services is the interconnectivity between the services, for example the ability to change the state of an issue ticket through a VCS entry. In our experience a very recommendable CPMS host would be assembla.com. The combination of services it offers is enough to fullfil most needs distributed teams have without becoming overly complex or unmaintainable. The clear and configurable user interface allows for swift project follow up, management and reporting. 11

See http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities for an exhaustive list

ICT PSP Project Reporting

206

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Even though it’s definitely possible to set up such a CPMS hosting yourself, this can prove to be a very daunting and time consuming task, requiring a lot of system administration skill and knowledge. There’s not only security issues to consider, but also user roles, service interconnectivity, system configuration, service accessability and system maintenance. A substantial setup and testing time should be scheduled for at the beginning of the project run time, before actual application development can commence. b. Version Control System (VCS)

The use of a VCS is emphatically recommended, it allows for keeping track of source code changes, creating “snapshots” of stable application states, concurrent development of various versions of the same application, avoids accidental code overwriting and in a sense even provides a backup system for source code when coupled to an online repository server. With distributed teams it is nearly impossible to develop a stable and scalable application without the use of a VCS. Your choice of VCS will depend on a few questions:

1. the knowledge/habit of the developers; are they already used to a specific VCS? 2. Will the used technologies impose a restriction on the possible choices of VCS? 3. Does the VCS have easy-to-use client applications for the type of operating systems used by the developers? 4. Does the IDE used by the developers impose or facilitate a specific VCS?

At the moment one of the most popular VCS’s is git 12, which was developed specifically for version controlling source code within distributed teams, but depending on the answers given to the questions above, maybe one of the alternatives is preferable: CVS, Subversion, Mercurial, a.o. 13

We strongly recommend git. It has a pretty steep learning curve and definitely needs a clearly defined workflow strategy (see d) but once the entire team has adapted to it, it alleviates most of the distributed application development pains. c. SCRUM

SCRUM is a methodology for technical project management. A full explanation goes beyond the scope of this article, but there are a very large number of resources to be found on the subject. We definitely recommend delving deeper into the matter, since a strict adherence to the methodology is imperative for its success. The idea of SCRUM is to have empirical process control. Actual project progress determines the planning and scheduling of the next phase of project advancement. It consists of an undetermined (ie. project and progress dependent) number of recurring iterations with a strict time range and rigorous practices in order to allow 12 13

See http://git-scm.com/ See http://en.wikipedia.org/wiki/Comparison_of_revision_control_software for an exhaustive list

ICT PSP Project Reporting

207

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

a project’s direction to be steered based on actual, completed work, not forecasting or speculation.

Especially important in SCRUM is a division of specific roles with particular responsibilities that represent the various possible interest groups: product owner (PO), scrum master (SM) and team member (TM). The PO is a proxy for the customer and stake holders. His main interest is the actual end result. The TM’s are responsible for the production of the application and consist of developers, designers, testers etc. The SM is the mediator between the PO and the TM’s, he’s the controller of the actual SCRUM process and the TM’s adherence to its methods. He’s also responsible for clearing any obstacles the TM’s might have that are straining the achievement of the agreed upon goals.

The main gist of SCRUM is to develop the application in a number of rounds (“sprints”). The final result of a sprint is always a potentially shippable product (“demo”). In the sprint planning meeting the PO, SM and TM’s determine together what the demo at the end of that sprint will exist of and what features of the final, full product will be included, by ascertaining the tasks at hand and their impact on TM workload. During the sprint (the actual development) the TM’s report to the SM by way of daily meetings (“standups”) in which they, very shortly, list out their progress, challenges and requirements in order to proceed. If problems arise it’s the SM’s job to solve them. At the end of a sprint a demo is shown to the PO and possibly other stake holders. Afterwards, during an evaluation of the demo (“sprint retrospective”) the entire team discusses the encountered issues, and what could be learned from them.

An important element in the SCRUM methodology is the use of a whiteboard, where tasks are listed and their progress is reported. With distributed teams a virtual, digital whiteboard is essential. Some of the CPMS hosts provide a number of services and tools that together form such a whiteboard. For instance assembla.com foresees standups and tasks (tickets) that integrate well with the VCS’s they offer. d. Development strategy

As mentioned in b a well defined development strategy is imperative. Also, due to the practices of the SCRUM methodology (see c) during the project timeline a great number of application releases will occur, which means it’s very important that all TM’s have a very thorough understanding of how they can work separately and consequently integrate their changes into the main body of work, with some modifications only targeted towards one specific release and others towards the final full product. This implies that the application will constantly exist in several states and versions at the same time. The strategy defines how these states and versions will be named in order to communicate their intent and also defines a way of working focused towards various versions. (1) Modularisation

ICT PSP Project Reporting

208

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The application should be divided into a number of modules or components that interact with each other. These modules should have clearly defined functionalities and should be testable and runnable independently. This ensures that changes (and especially bugs introduced by these) in one part of the application do not have a negative impact on another. Also, since functionality is encapsulated it allows a TM to focus on one specific functionality and progress without being dependent on another TM’s changes.

In order to let the modules interact with each other they need to expose a public API14, a restricted number of properties and methods that can be viewed and called by the other modules in order to have two-way data exchange between these modules. It’s essential that these API’s are well documented and that these documents are publicly (ie. for all TM’s) available. Again, a decent CPMS host will provide a way of sharing these documents with the entire team. Such a public API can consist of the definition of a webservice that can be called through an HTTP request or it could simply be a façade class with callable methods that dispatches/delegates these calls to other classes, when modularisation is not restricted to system or framework boundaries, but also occurs within one environment. (2) Semantic versioning

Since the application will exist in different states and versions at the same time, it is very important to have a structured, clear and strictly defined way of naming and annotating these versions.

But not only the application state should be versioned, also the different modules need to be versioned separately. Since the modules interact with each other and are modified independently of each other, it means that a module (slave) that is dependent on another module (master) will assume that master has a very specific API and functionality at that given time. In other words it is dependent on a specific version of the master. If the public API of the master changes it can have a very drastic and negative impact on the slave, therefore the developer of the slave needs to be able to not only identify a module’s version, but also must be able to interpret how “grave” the changes to a module were in between versions. Semantic versioning aims to solve this problem of version naming and change-scope identification. Our recommendation is to use a variation on a public semantic versioning specification developed by Tom Preston-Werner 15. It differentiates application or module state changes in 3 degrees: major, minor and patch.

A single version number consists out of 3 integers, together representing the level of change in between versions. [major].[minor].[patch] 14 15

Advanced Programming Interface See http://semver.org/ for the full specification

ICT PSP Project Reporting

209

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

When a new version of a module is released (ie. made available to the developers that are using that module) the elements of the version number are modified, according to specific rules. An element integer is either incremented – or – reset to zero if its hierarchically superior element is increased. To determine which element needs to be incremented use the following rules: • • •

[major] Entire rewrites with public API changes, that break backwards compatibility [minor] public API changes, bug fixes or functionality changes that do not break backwards compatibility [revision] Non-public API changes, code improvements (w/o changing functionality), small bug fixes or esthetic changes.

For example:

A module has version number 1.3.2

If the developer makes a small code improvement, for instance optimizes a certain algorithm and releases it to the team the module will get version number 1.3.3 If however he adds an optional parameter to a public API method it will be named 1.4.0

And in the case of a major rewrite or for instance he adds a method to the public API the module gets number 2.0.0 (3) Development workflow

Ideally developers should have the freedom to make changes to their code (and even of others !) without it interfering with the changes other team members are making and then, only at certain times “publish” (ie. release) their changes so that the entire team is able to make use of those modifications. On the other hand, a developer must also be able to ignore published changes and still use old versions of a particular module in order to be able to focus at the changes he’s making and not be distracted by possible differences in functionality or API that the modules he’s depending on are introducing. Our workflow recommendation is entirely based on the use of git, since it fullfils the above development workflow requirements. Other VCS’s possibly too, maybe with a slightly different workflow. This is a pretty technical explanation and assumes the reader has an understanding of the git repository model and knows how to use git. a. Branching

Our application always exists in (minimum) 2 separate branches: “master” and “development”.

ICT PSP Project Reporting

210

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

All code that resides in master should either be in the latest released application state (when following SCRUM, that would be the last demo) or in a state ready to be released (ie. the next demo) Either way, if you take the code from master and build the application from it, you should always get an executable and working version of the application.

The development branch holds the code with which that next version of the demo is being constructed. However this is not simply all the changes of all of the developers put together. These are the versions of the modules that the developers thought were stable or beneficial enough to be published to the entire team.

A developer always works locally. When he starts working on a feature, he creates a new branch (preferably with a semantic name) and records his changes locally (from here on referred to as a dirty branch). Obviously if the wants to share the code he’s working on (for instance let a TM review it) or he needs to be able to access it from another computer he can publish this dirty branch remotely. A dirty branch is only merged into the development branch if and when the feature or set of changes is finished, ie. if it’s usable for other TM’s. Then the dirty branch is deleted both locally and remotely. b. Tagging

Tagging is used to denote application states in the git commit history. A tag should point to code that generates that specific version of the application state.

If an application is released it should be tagged immediately and appropriately. No exceptions. There are three different kinds of application states we're interested in tagging:

• • •

Production (semi-dirty) restricted releases public releases

Production tags or snapshots are made to point at stable application states you could want to be able to return to in the development branch, the code is not yet ready for release, but for some particular reason its state is interesting enough to create a snapshot of . Restricted releases are for demoing or testing. (SCRUM demos are also restricted releases)

Public releases are when the application is released into “the wild” and will be used by the general public. Tags should be made following this format: xYYMMDDi-semantic

x is one of the following values [p,q,r]

p: production q: qualifying (restricted releases) r: release (live, public releases) ICT PSP Project Reporting

211

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

YYMMDD - or - YYYYMMDD The date, backwards: [year][month][day]. For example: 20110913 or 110913. doesn't matter which of the two formats you use, as long as you're consequent with the other tags i (iteration)

i is simply an iterative value to denote several snapshots for the same date. Best to use the alphabet instead of numbers though for reasons of readability since it's glued to the date.â&#x20AC;¨i= [a-z]

semantic

Whatever makes sense for the snapshot kind. For instance for production snapshots it's best to choose a word (or words) that denote the snapshot state. Example:

p20111004a-cleaned

For qualifying and release snapshots it's best to follow semantic versioning guidelines as described above (semantic versioning)

For example:

q20111012a-v0.9.3

ICT PSP Project Reporting

212

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

15.

Community Reporting Tool

Contributor: UP8 15.1

Problem or requirement addressed by the Method

The major requirement was to explore the feasibility of developing a cross border European Community Reporter programme which the other living labs could use. The work is based on the eParticipation pilot within APOLLON. The two main issues that have been explored within the eParticipation pilot were: â&#x20AC;˘ â&#x20AC;˘

The cultural relevance of such a programme

The barriers to developing a Europe wide Community Reporter programme

15.2

Description of the Method

This method describe how to set up a community reporters group: what are the important factors to consider, how to motivate participants, what are the free tools you can use, and what are the cultural variables to consider when you try to train people on becoming Community Reporters. Stage 1: Understanding the model and learning the skills

Stage2: Duplicate the experiment in a different cultural setting

Stage 3: Review and evaluate and determine the lessons learned 15.3

Use of the Method

This method can be used to set up a Community Reporter group and as an outline for training Community reporters. 15.4

Implementation of the Method

1) What are the important factors to consider?

Can anyone join the programme? Anyone can become a Community Reporter; age, language, health issues or disability....none of these are factors that stand in the way of someone becoming a Community Reporter. Bearing this in mind, it is therefore important to consider how you are going to promote the opportunity. Are you going to open it all? Or target a particular age group? Or target a community of interest eg members of a local history group? Or target a community of need eg Stroke survivor support group? You might also want to think about keeping the content open or defining the content around a particular topic eg mental health or crime. How will you do your engagement? Is this through direct contact, working with other agencies or by training and badging people who already are producing content?

Who will be funding the activity? This could be through the generating of income via the marketing and selling of content or though public grants around increasing voice or improving employment prospects. If money is received through public

ICT PSP Project Reporting

213

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

grants then there may be a fear by the funder that harmful content would be created by Community Reporters. You will need to show them the Best Practice standards to ally these fears.

How to arrange training location and equipment issues? You will need to consider where the training is going to take place – ideally you will have access to a training room with PCs and Internet access. And who will provide and look after the equipment that the reporters need to use – will this be managed by a project or will reporters be encouraged to use their own equipment e.g. mobile phones? The PreTraining Questionnaire gives a full overview on issues you will need to consider before conducting Community Reporter activity. 2) How to motivate them: We motivate learners in a number of ways: •

•

Peer learning and peer support: the programme is structured as an informal process. Although there are tutor led activities we work hard to value the skills and knowledge that each participant brings to the process. There is a skills audit to start this process and then activities where learners work in small groups, problem solving and sharing ideas

Consolidation exercises out in the community: the programme is a combination of classroom based learning and community based activity. Providing people with real life reporting opportunities to put their new skills into practice is extremely motivating as reporters can see the benefit and support they are offering to their community.

Peer review: encouraging the learners to review each other’s work motivates them to improve their work but also builds a real bond between the members of the group as it nurtures a supportive environment for development.

Meet ups: built into the structure is the chance for learners to continue to meet on a regular basis as a self-supporting group. In the group they will continue to skill share, review and comment on each other’s work and plan to buddy up on projects. This sustainability is vital to keeping Reporters motivated in the longterm.

3) What are the free tools you can use?

The market in social media tools is ever changing, with new and easier tools becoming available which are often available in multiple language formats. The advantage of this is, although the training material might need to be updated, the basic technology and interoperability of the content can remain static and be fed between the different tools, thus making content available to different people. In addition, although the language is different, the implementation is often the same. This means that the broader European network can crowd source solutions to problems. Based on the current market we would suggest the following tools; • •

Story – wordpress.com Photo – picnik.com

ICT PSP Project Reporting

214

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • •

Audio – Audacity

Video – jaycut.com

Resources – flossmanual.net

Distribution – Facebook, Twitter

4) What are the cultural variables to consider when you try to train people on becoming Community Reporters?

The basic principle of Community Reporting is about giving voice to individuals and communities so their perspective can be heard, they can describe their own reality and that dialogue is encouraged in order to reach innovative local solutions. These principles are embedded within most democratic societies and therefore should not be too controversial. However, the Community Reporter Programme would struggle to be effective if these principles were not accepted. The same is true of access to the Internet. The programme relies on the freedom of information and exchange of information between people and government. Again, if these were not available the programme would not be as effective. The programme offers flexibility and adaptability by the participating agency and does require a level of entrepreneurship in the marketing and development of the programme. The key success factor would be that these values exist within the organisation promoting the programme. ANNEX

Example from the work carried out in WP5 during Apollon.

Stage 1: Understanding the model and learning the skills Five members from Issy-les-Molineaux visited Manchester for two days of training in December 2010.

Day One:

They were taught the basics of the programme – our approach, the informality, the peer support and learning, peer review. They were also taught the importance of Editorial Guidelines, getting consent, health and safety for reporters and copyright – these are the elements that make up what we call Community Reporter Best Practice. Next were some skills training around video techniques, interview techniques and how to conduct oneself when out filming in public. That evening, the group were all set the task of reporting in the community. They were all able to put the skills training into practice and record interviews with members of the public (one member of the group was lacking in confidence in his English so he videoed without interviews). Day Two:

ICT PSP Project Reporting

215

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Now the group were taught how to edit using Windows MovieMaker. They had different versions of WMM which flagged up some issues they might face when transferring the training to their own centres. They used their own footage from the night before to edit short films about their experiences. Next came blogging training using Wordpress. Wordpress has the option for numerous languages so the group were able to use French Wordpress. One member of the group already used blogging software but felt that Wordpress was much more easy to use and had more functionality. The group then uploaded their videos to the blogs and ended the day with video evaluation of what they learned and how they hoped to take it forward. Comments included: ‘most importantly we learned a methodology’

‘we learned small things that were easy to replicate’

‘the training was very practical so we’re up to doing the same thing in Issy’ Stage 2 : Duplicate the experiment in a different cultural setting

The group returned to Paris and began the process of recruiting in early Spring. We offered remote consultancy via email and Skype. Issy targeted young people as one of the people who completed the training was from a young person’s project in Issy. They felt that the word Community Reporter did not translate well and therefore changed this to ‘Web Reporters’. These Web Reporters went out interviewing members of the public about the multimedia trail that was being deployed across the city. Content can be viewed at their blog here: http://issyreportages.wordpress.com/

And on our website: http://communityreporter.co.uk/videos/trained-manchesteryoung-french-community-reporters-report-event-paris

Issy modified the reward system and included the badges (as per UK Reporters) and hats (rather than the T-shirts used in the UK). The use of the QR code on the hats is a great improvement and one that we will look to implement in the UK. The French pilot confirmed the value and importance of making Reporters feel like they were part of wider group.

People’s Voice Media had the chance to visit the group in June 2011, to see what content they’d created and to interview them about their experiences. This reinforced the sense of being part of a international group and we were keen to have their content shared on the communityreporter.co.uk web site. One of the Parisian reporters is included in a film about Community Reporters on the about page of communityreporter.co.uk website. The young person’s project is looking to repeat the activity in the Autumn 2011. http://communityreporter.co.uk/about-us ICT PSP Project Reporting

216

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Stage 3 Review and evaluate and determine the lesson learnt This took place through informal interviews during the Paris visit and also in the form of a film.

ICT PSP Project Reporting

217

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

16.

Platform for Cross Border Trading of Services

Contributor: SAP

16.1 • • •

Pre-Requisites/Assumptions

You have a service which you would like to offer in another country

You have a product which you would like to offer in another country

You have a product/service which you want to introduce/test to/at the market and/or a new market

16.2

Problem or requirement addressed by the Method

Service providers (in particular SMEs) require a mechanism to offer and trade their services across borders in new target markets, because they usually do not have the seize and the money to invest in market research or business development nor do they have large budgets for promotion/marketing. In particular when they need to find early adopters and future customers for new product/s in a market they are not familiar with, they would need local partners who know the business environment.

An Internet-based trading platform or a marketplace amongst networks of Living Labs that offers access to end users and consumers, especially demanding innovative products and services in the industry they are targeting at, would help to moderate the processes of finding the right partners, users and future customers to incubate business collaboration. 16.3 Description of the Method

Whilst the main focus of trading in the services industry is on electronic services (e.g. web services for electronic device integration, remote maintenance services) an Internet-based platform or marketplace may also cater for B2B services that require local/on-site interaction (e.g. consulting or set-up of systems). Such a trading platform or marketplace could provide support for •

• • • • •

Describing a service from a technical, functional and business oriented view (e.g. pricing, technical access specification, usage, regulatory and legal restrictions) Describing und publishing the request for a service, help, support… Matchmaking between service offers and service requests

Trading of software modules developed by independent software and service providers

Offering and selling the software and software modules via a web channel (web shop) Deploying a service electronically into a service runtime

ICT PSP Project Reporting

218

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • • •

Finding local partners providing relevant on-site interaction with a user/customer Finding market-compliant local technical components

Keeping track of the service implementation and usage

Allowing to certify service offers incl. their service providers

Pricing and billing of the goods and services traded via the platform.

16.4

Use of the Method

In order to satisfy the need for business creation and extended access to foreign markets for SMEs the platform allows service providers to offer their services across borders in a network of Living Labs.

You –e.g. the Living Lab– should set-up such an Internet-based platform with a marketplace interface for the domain network you are participating in, allowing for registration of the participants and description of the services and products they would like to offer, locally or abroad. It would help if you brand your marketplace according to the strengths and potential your domain network offers. The party offering the Internet-based platform with a marketplace interface and the party technically hosting and running it, could be different. Anyone from within or outside of your domain network, who is interested in exploring the local environment for future business, should be able to use an editor to describe their service and their requests for local partnering.

The platform either offers an automatic match-making or orchestration or you should have a moderator who frequently scans for new offers and requests in order to get in touch with the participants and connect them further or participants can directly either access a request for quotation or service need. 16.5

Implementation of the Method

To set up and use the Internet-based trading platform or marketplace the following activities are proposed: Activity

Responsibility

Deadline

Outline and specify requirements for cross border service trading

service provider

when ready to move

service provider and local partners

before going-live

Evaluate the appropriateness of existing platforms for cross border service trading Set-up the platform Design a trading scenario based on the existing and implemented local use case/s

Prototypically implement and test the trading of your service with the local partners

ICT PSP Project Reporting

219

domain network / Living Lab service provider and local partners

once

when ready to move

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

16.6

Experiences with the Method

Experiences with the method are described in the three-monthly monitoring reports for methodology validation, for Q4/2011 and Q1/2012. 16.7

Example

Within the APOLLON project manufacturing experiment, the service provider runs an interoperable middleware platform for device integration (in this case the DMI from SAP Research’s Living Lab in Dresden). Based on different use cases this service provider develops so-called “agents” to connect & integrate various devices and develops cockpits/UIs to provide the information gathered, related to the specific use case to the customer.

One use case was about “energy monitoring”: identifying the suitable smart meter, connecting it to the machine and developing the adapter to connect it to the middleware platform, developing the UI to provide the real-time data from the energy consumption in a cockpit, that serves the customers needs, which was daily, monthly and real-time view.

The SME decided to offer the energy monitoring service abroad and thus needed to find partners that could offer market-compliant smart meters and that could go and set-up the devices and systems on-site at the customers premises. In APOLLON we used the USDL editor from the THESEUS/Texo project to describe the “energy service”, the “smart meter product offer” and the “on-site set-up service”, we used the THESEUS/Texo marketplace software to set-up and describe the APOLLON manufacturing domain marketplace and demonstrated how the match-making would work within the Portugues market.

In a second trial, we invited the partners from the APOLLON energy experiment, to access the APOLLON manufacturing domain marketplace and to search for an energy monitoring service, to provide” local-market-compliant smart meters” and “local on-site set-up services” and thus to find a new market access, within two other countries, for the SME from Portugal during this trial. The other example of tradeable services besides this plant energy monitoring and management was the tracking and tracing of tools and material in a factory environment. 16.8 • • •

Further information and Links

Internet-based platforms, marketplaces: http://en.wikipedia.org/wiki/Marketplace

Internet of Services: http://en.wikipedia.org/wiki/Internet_of_Services Website of THESEUS research program website: http://www.theseusprogramm.de/en/index.php

ICT PSP Project Reporting

220

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

• • • •

o Website of TEXO application scenario: http://www.theseusprogramm.de/en/914.php o Website of THESEUS innovation center: http://www.theseusprogramm.de/en/innovation-centre.php - Video about the innovation center: http://www.theseusprogramm.de/en/1431.php Internet-of-services by SAP Research: http://www.internet-ofservices.com/index.php?id=260&no_cache=1&L=0

What is USDL: http://www.internet-of-services.com/index.php?id=264&L=0 Where to get the USDL editor: http://www.internet-ofservices.com/index.php?id=290&L=0

Where to get the THESEUS/Texo marketplace tool TBD

ICT PSP Project Reporting

221

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

17. Remote Guided Living Labs Tour Using Webcam and Webconferencing Contributor: SAP 17.1 • • • •

Pre-Requisites/assumptions

You have a local “physical” environment, where you already offer onsite guided tours for visitors

You have worked out a story (script) for the tour, which you want to tell, during a tour You have worked out scenarios (scenes) that seamlessly integrate the demonstrations along the tour into your story

You have worked out a storyboard for the tour, which enacts the technical demonstrations, lights, inputs …

17.2

Problem or requirement addressed by the Method

Customers always ask for references and showcases in a real-world setup of technologies and services they are interested in. For cross-border businesses it is sometimes very difficult for both business partners to either get sufficient information about the technology offered by a provider or to find out about the real requirements of a customer, as the involved companies are far away from each other.

There are travels required either to visit each other or to meet at trade fairs, to get a better understanding of the needs and the potential value, which implies high costs, you are usually trying to avoid in early stage investigative actions or negotiations.

The combination of video and audio for online demonstrations in a live and interactive mode is therefore highly of interest. 17.3

Description of the Method

You have to set-up a webcam within your premises in a way that you can follow the person, acting as the guide through the story of your guided tour and your technology demonstrations which you plan to convey through the remote guided tour. You need to have a person, managing the webcam through mouse or you choose one with tracking capabilities which thus can follow the guide automatically. If you need to install more than one camera to reach out to all your demonstrations, you will need to have systems and software providing you with a cockpit to manage several web cams.

In addition you need at least to set-up an audio conference, so remote visitors can listen to the guide talking. If you plan to show some introductory slides, before you start the remote tour, an online application sharing software would be necessary. Online conferencing solutions usually include both. ICT PSP Project Reporting

222

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

You need to send the LINK to the online conference and to the site you have set-up to follow the webcam and the dial-in numbers to the remote visitors. You should try it out with colleagues and friendly users first, improving the interaction with the camera and the conspicuousness of the demonstration before you start inviting potential partners or customers.

You should prepare a feedback questionnaire with all parties involved, who want to get feedback on e.g. the overall story, the vision, the single demonstrations, the technology usedâ&#x20AC;Ś and think about different means of providing the questionnaire and collecting the feedback, as e.g. directly during the session, online, through email afterwards â&#x20AC;Ś. 17.4

Use of the Method

The webcam tours can be either offered as regular events (e.g. on a quarterly basis) or could also be setup on demand for interested customers.

With regards to the individual setup these webcam tours can either focus on a certain scenario or technology (usually if a customer is interested in a particular solution) or can be generic webcam tours, showing the complete solution stack installed in the Living Lab. For one-customer presentations it makes sense, to adapt the story to the specifics of that customer, to make it more intriguing for the participants of the session. Local SME's and partners working together with you in and around the Living Lab are thus able to demonstrate their (integrated) solutions to every interested party or prospect regardless where they are located.

After the tour you should offer time for Q&A and have prepared some questions to stimulate the discussion. If you are having a very experienced tour guide it may be even more interesting for the participants of your remote sessions, if you offer that people can ask questions any time; this might be especially helpful for the onecustomer-sessions, where you want to be sure, you meet the expectations. For the feedback collection it is important to consider only those parts of the questionnaire that directly relate to the respective session that was given. 17.5

Implementation of the Method

Activity

Responsibility

Deadline

Setup of technical infrastructure for the webcam tours

Technical team

once

Preparation of webcam tour announcements and invitations

marketing team

once

Identification of webcam tour dates

Preparation of a modular feedback questionnaire and ICT PSP Project Reporting

223

Tour guide; Tour guide and potential customers Demonstration owners;

n/a

once

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines related announcement/s

partners; tour guide; … technical team

day of tour

Feedback collection, related to the respective session given

tour guide; partners

After tour

Start technical infrastructure for webcam tours Run Webcam tour

17.6

technical team, tour guide, if necessary, technical partners

day of tour

Experiences with the Methodology

The service and/or technology provisioning and consumption are very well supported. Specifically the supplier evaluation will be improved as potential customers get better information about the quality and the potential of the respective service and /or technology of their potential suppliers. Discussions and Q&A are way more lively and interactive then when only providing presentations. It seems that participants more have the heart to ask questions. 17.7

Example

For the initial collaboration within the APOLLON project manufacturing experiment to convey what the Future Factory Living Lab is all about, the colleagues of SAP Research in Dresden are using a stationary installed webcam with 360° roundtrip capabilities and LAN connection in combination with audio conferencing to introduce the real world test bed. •

• • •

Webcam: camera Axis 213 PTZ, which has a 10x optical zoom and a very good resolution and web-based features (360 degree turn, zoom, pan, focus).

Software: comes together with the camera hardware

Audio: Telephone conferencing

Online collaboration: Adobe connect

An invitation to the Future Factory web cam tour looks as follows: Second Webcam Tour through the Future Factory of SAP Research in Dresden.msg

A feedback questionnaire for the full blown generic tour looks as follows:

ICT PSP Project Reporting

224

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

17.8 • • • • • • •

Further Information / LINKs / Literature

How to write a storyboard: http://www.wikihow.com/Draw-Storyboards How to write a script: http://www.wikihow.com/Write-a-Script What is storytelling: http://en.wikipedia.org/wiki/Storytelling What are webcams: http://en.wikipedia.org/wiki/Webcam

What is application sharing: http://en.wikipedia.org/wiki/Application_sharing Adobe conferencing solutions: http://www.adobe.com/products/adobeconnect.html www.sap.com/futurefactory

ICT PSP Project Reporting

225

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

18.

Test Storyline for user communication

Contributor: LTU-CDT 18.1

Objective of the method

This method strives to contribute to the design of the test assignments in an innovation process. By using this method it is also possible to design tests in similar manners across borders, hence, this method supports knowledge sharing as well. By means of this storyline, knowledge on methods, questions and approaches can be shared among the project partners. This template is also aimed at supporting the communication between the Living Lab and its users to make sure that they understand what is required from them during the test they plan to enter. The intended usage of the guidelines is to support the design of the user tests. 18.2

Description of the method - Test Storyline

This is a template that guides the process of designing a test that is planned tob e carried out for a longer period of time. These tests are carried out in private persons homes and should hence be planned carefully. To support the user test, a document containing the headlines below should be developed and distributed to the users before the test with the objective to guide the users and to:

1. Start with defining the test duration time – describe the time frames for the test 2. Test assignments – Describe the test from an overarching perspective, what the test is about, what the users can expect from the test etc. 3. Technology description: Describe the technology that they will recieve in the test from an overarching perspective. For example, When the installators are coming to your home and installs the technology, you will get the following equipment: • The technology •

• • •

User manual

User agreement

Test instructions

Important! Before the installators leaves you must sign the user agreement where the loan of the equipment is described. Follow the instructions below to carry out the test

4. Describe the test in detail: • What you expect the users to do • •

Why you want them to do that

How you are going to interact with them

ICT PSP Project Reporting

226

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

•

Etc..

5. Describe the functionalities of technology Here a description of the functionalities of the technology the users should be testing sho uld be presented. This description should focus on the functionality of the technology and how the users can use it. Not a technical description. What kind of information can the user get, how do they navigate etc.

6. Evaluation of the test

Describe how the test is going to be evaluated and finalised.

7. Thank the users!!

18.3 Overarching Test storyline for an energy consumption monitoring technology – Example questions and tasks This test storyline is meant as a tool for the designers of the test where they can make sure that all the functionalities of the technology are covered while at the same time the tasks the users should carry out are both meaningful and related to the functionality that should be tested and evaluted. Month

Assignment

Question areas

April

Radio/TV/Tele

Was there any difference in energy consumption?

May

Laundry and drying •

• ICT PSP Project Reporting

Measure the energy consumption during night time an ordinary night and note it down, also note the outside temperature Turn off all unnecessary energy consumers such as lamps, stand-by TV, computers, phone loaders, etc Measure the energy consumption for that night and note it down also note the outside temperature Note which day of the month that had the highest level of energy consumption

Measure the energy consumption when you wash your laundry in 90, 60 and/or 40 degrees and with different programs. Note the energy consumption 227

Which equipment did you turn off? Do you think that you will continue turning these off? Which consequences would that have for you? What was your experience of doing the assignment?

What was the difference in energy consumption between the dffferent degrees?

Do you think that you will change your washing routines due to this information? Why, why not? Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines â&#x20AC;˘

ICT PSP Project Reporting

for each washing machine If you have a tumbler dryer that you use, please note the energy consumption of a machine

228

Compare the energy consumption between April and May

Is there a noticable difference between the months? If so, what might be the reasons for the difference?

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

19.

Designing Use Transformation Processes

Contributor: LTU-CDT

19.1

Problem or requirement addressed by the Method

In this method, the overarching goal is to support the design of a process that is focusing on studying use transformation among users of innovative technology. Based on that, this method is targeted at stimulating the use of new technology, which in turn influences user behavior. The aim of this method is to provide SMEs and Living Lab managers with a framework that facilitates the design of user involvement studies. The process is also designed to support knowledge sharing between experiments to facilitate the possibility that the results from an experiment can be compared with other experiments since the set up of the experiment is similar and considers similar matters. The aim of this method is to support and stimulate users to change usage of technology by stimulating them to use the implemented innovation. The underlying proposition is that users that are guided and encouraged to use innovations are stimulated in their innovation decision processes which in turn leads to changes in their social systems where behavior is one part. This framework should be envisioned as both a framework to guide the process of the experiments set up, but also as a template for documentation of the case. This is important in order to make it possible to share knowledge between different stakeholders. 19.2

Description of the Method

First step: Case description To support knowledge sharing and to get a coherent view of the context in which the study is being undertaken, it is important that the project or case is described in some detail. 1) Describe the background of the case • • • • •

Define the purpose of the case

Identify key-questions to be answered State the research questions

Describe the innovation to be implemented in the users context

Define the partners in the project (who they are and what are their competence area is)

2) Determine the time frame: • Specify the duration of the case as well as the duration of the test as such ICT PSP Project Reporting

229

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Second step: set-up phase of the use transformation process 1) Define which technology to implement in the users context •

Define the functionalities of the technology (determine all that is possible to do with the technology). This will guide your design of the case later on.

2) Decide on whom to involve in the study (the user groups) • • • • •

Who the users are (e.g. age, gender, educational background, technology usage, consumption habits)

How many users you should involve. The appropriate number depend on what you want to achieve with the study

Where they can be found (e.g. established groups, students in a course, shoppers etc.) How they can be contacted (e.g. mail, phone, on-line community)

Which selection criterions you should have. Suggestions for selection criterions when focusing on energy saving for instance can be:

• gender • how many adults and children that lived in their home • the age of the children • how they live (house, apartment etc) • what kind of heating they have in their home • the size of their house • if they plan any renovations in their house, ( if, so which), • their interest in energy saving questions • etc… 3) Divide roles among partners • Define responsibilities of activities during the case and the test (e.g. who are responsible for contacting users, installation of technology, support during test) Third step: Design the Process

In this section the focus is on the design of the process for the use transformation process. In this process it is important to be aware of what the users should be doing and when they should do it in order to track the process and stimulate use transformation which in turn increases diffusion of innovation. The process for the use transformation study can be organised as follows: a. Start with training sessions to learn about the technology among all partners involved b. Do functional testing within the Living Labs or among the SMES to make sure that the technology is working and to become acquainted with the technology before the design of the tasks for the evaluation is done c. Translate instructions, screen texts, messages and other information if needed ICT PSP Project Reporting

230

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

d. Decide on user interaction technologies to be used (surveys, communities, social media etc)

e. Decide on how to evaluate the experiment f. Recruit the participants

g. Select the participants

h. Set up collaboration agreements and other legal agreements among partners

Develop tools for comparing results from the implementation of the technology. For instance, develop a base-line questionnaire with questions about their current behaviour, interest etc. This baseline questionnaire can then be distributed to the selected users in the beginning of the case and in the end of the case to be able to measure changes in their self-reported behaviour and interest in the topic being studied. Determine how user input will be gathered and develop sufficient tools

k. Develop user interaction scheme containing: i.Frequency of user contact (e.g. every week, every month) ii.What kind of contacts it should be (e.g. personal visits, e-mail, SMS) l. Develop a test-storyline (see method â&#x20AC;&#x153;test storylineâ&#x20AC;? for more information) containing: i.activities the users should do ii.time schedule for when they should do what iii.technology to collect their experiences of the activities, their behaviour change and their attitudes. m. Keep track influential factors that might influence their behaviour but is outside the scope of the project. n. Make sure to tasks for the users to carry out in accordance to the situation, for instance the season. Fourth step: Technology implementation 1) Install the technology in the field.

If a technician is needed to do the implementation, provide one. Otherwise, make sure that explicit implementation instructions are provided to lower the threshold of start using the innovation. a. Interact with the users according to the test storyline. After each interaction, self-evaluate the approach to make sure it gives the needed input. If not, make needed adjustment in correlation with the purpose of the case b. After the test is finalised, conduct the same base-line questionnaire again to be able to compare the results and measure some input c. Evaluate the users experiences of using the innovation, taking part in the test and their behaviour in general. d. Document the findings and reflect to learn for the next user study. ICT PSP Project Reporting

231

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

19.3

Use of the Method

This method is to be used to support the design of the energy technology experiments in peoples real life context to support the users to change their behaviour and to adopt energy technology. 19.4

Implementation of the Method

The method has been implemented in WP3 energy pilot where it has been used to guide the process of stimulating users to change their behaviour and hence adopt the innovation. 19.5

ANNEX: Background on Diffusion of Innovation

Studying how behavior changes when a new technology has been implemented into a specific context is complex. It is difficult to determine what has caused the change as well as understanding all the different factors that might influence the behavior change. Firstly, it is important to understand that the technology being implemented actually has been adopted and used by the users in the context. One way to study that is to apply the diffusion of innovation theory in the context and thus stimulate the users to adopt the innovation. The diffusion of innovation is essentially a social process in which an innovation is communicated through a certain channel over time among the members in a social system. Communication is a process in which participants share information with one another in order to reach a mutual understanding. Diffusion is a special type of communication in which the messages are about a new idea. The newness if the idea in the message content gives diffusion its special character. The newness means that some degree of uncertainty involved in diffusion. Uncertainty is the degree to which a number of alternatives are perceived with respect to the occurrence of an event and the relative probability of these alternatives. Uncertainly implies a lack of information. Information is a means to reduce uncertainty. Information is a difference in matter-energy that effects uncertainly in a situation where a choice exists among a set of alternatives. Diffusion is a kind of social change. When a new idea are invented, diffused and adopted or rejected, leading to certain consequences, social change occurs. Hence, diffusion is the process by which an innovation is communicated through a certain channel over time among member of a social system. Here, an innovation is an idea, practice, or object that is perceived as new by an individual. The characteristics of innovations help to explain their different rates of adoption. These characteristics include the following: 1. Relative advantage is the degree to which an innovation is perceived better than the idea it supersedes. 2. Compatibility is the degree to which an innovation is perceived as being consistent with the existing values, ast experiences, and needs ot potential adopters. ICT PSP Project Reporting

232

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

3. Complexity is the degree to which an innovation is perceived as difficult to understand and use

4. Triability is the degree to which an innovation may be experimented with on a limited basis. 5. Observability is the degree to which the results of an innovation are visible to others.

The second element of the DoI theory is Communication Channels, refers to the means by which message about an innovation are transmitted among members of a social system. Information regarding the innovation has to be disseminated so as to introduce the innovation, form or change attitudes, influence decisions regarding the innovation and support the evaluation of the innovation. The third element is Time of diffusion, which focuses on three dimensions namely, the decision making processes, an individuals’ innovativeness and the rate of adoption. The fourth element of diffusion is the social system which is defined as a set of interrelated units such as individuals, groups, organizations, subsystems, that are engaged in joint problem solving to accomplish a common goal.

However, understanding the different elements of diffusion is not enough, it is also important to understand the innovation-decision process. This is the process through which an individual passes from gaining initial knowledge of an innovation, to forming an attitude toward the innovation, to making a decision to adopt or reject, to implementation of the new idea, and to confirmation of this decision. Rogers identified five distinct stages in the process of diffusion of any new initiative or innovation. These are: • • • • •

Knowledge occurs when an individual is exposed to an innovation’s existence and gains an understanding of how it functions Persuasion occurs when an individual forms a favorable or an unfavorable attitude towards the innovation Decision takes place when an individual engages in activities that lead to a choice to adopt or reject the innovation Implementation occurs when an individual puts a new idea into use

Confirmation takes place when an individual seeks reinforcement of an innovation-decision already made, but he or she may reverse this previous decision if exposed to conflicting messages about the innovation.

Rogers argued that the diffusion of an innovation is enhanced when the perceived superiority of an innovation is high compared to existing practice (i.e. the relative advantage), and when the compatibility of the innovation with the existing social system is perceived to be high (i.e. compatibility).

In various stage models of behaviour change that have been proposed over the past two decades, Owen and Lee (1984) highlighted a number of commonalties they share. ICT PSP Project Reporting

233

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

These authors propose an integrated stage-based model in which behaviour change is viewed as a cyclical process that involves five stages of: 1. awareness of the problem and a need to change 2. motivation to make a change

3. skill development to prepare for the change

4. initial adoption of the new activity or behaviour, and

5. maintenance of the new activity and integration into the lifestyle.

ICT PSP Project Reporting

234

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

20.

Checklist to prepare for product or service introduction

Contributor: SAP 20.1 • • •

Problem

You have a service which you would like to offer in another country

You have a product which you would like to offer in another country

You have a product/service which you want to introduce/test to/at the market and/or a new market

When a complex product or service is being offered it is necessary to make sure the customer is aware of all requirements of the product. These requirements can be hardware, software requirements, resources needed, etc. In the anticipated remote international environment you also have to rule out discrepancies in different naming of processes or features, different definitions and different working approaches. Therefore a checklist is used to assure that features and functions of the software and assets are synchronized and discrepancies due to different nomenclature are avoided. This checklist is also a way to make sure partners are aware of all requirements.

Implementations or similarities to these checklists are quite common in multinational business areas. Since the emphasis chosen for the APOLLON project is to support SME in building up cross border business opportunities this method should be adapted. The supported processes are the Connect as well as Plan & Engage phase of the experiment. 20.2

Method description

The intended use of the method is to prepare the implementation of a new product or service for a customer, remotely. The checklist is implemented to secure all requirements are fulfilled and there are no misunderstandings. The checklist is to be derived from the functionality of the offered product and experiences with it. It has to include questions and guidelines concerning: • • • •

Required Assets, hard- and software

Needed skills

Expenditure of time for each activity during the implementation process

Contact persons for each party involved in technical, business and administrational support

ICT PSP Project Reporting

235

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

The intended use of the method is to prepare the customer for the implementation of a product or service at their site. The checklist is implemented to secure all requirements are fulfilled.

The provider has to prepare a checklist including all the components important for product/service implementation. Customer and provider have to determine missing requirements based on the answers as well as clearing misunderstandings due to cultural differences. In some industries (i.e. mechanical engineering) checklists are developed between provider and customer starting out an international project. The supported processes are the Connect as well as Plan & Engage phase of the experiment.

ICT PSP Project Reporting

236

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

21.

Checklist to implement a use case in another environment

Contributor: SAP 21.1

Problem

An existing use case is to be implemented at another factory site.

Since the collaboration between the living labs is done remotely in different countries, issues have to be addressed in terms of different naming of processes or features, different definitions and different working approaches. Therefore a checklist is used to assure that features and functions of the software and assets are synchronized and discrepancies due to different nomenclature are avoided. This checklist is also a way to make sure partners are aware of all requirements. In the factory environment of the experiment there are numerous requirements for the setup of the specific use cases. These requirements are identified as functional and non-functional requirements. In order to successfully implement the use cases, these requirements need to be fulfilled. The supported processes are the Connect as well as Plan & Engage phase of the experiment. 21.2

Description of the method

From the experience of implementing the use cases at Future Factory Living Lab a checklist has been derived to support implementation at the other LLs. The checklist contains requirements and questions that are grouped into two categories: â&#x20AC;˘

â&#x20AC;˘

Functional requirements: Specific requirements for the use of the software as well as the technical implementation at site make up the category of functional requirements. Non-Functional requirements: The non-functional requirements include security, performance, resource requirements, activities and time planning.

The intended use of the method in WP4 is to prepare the experiment and the implementation of the use cases at each participating living lab. The checklist is implemented to secure all requirements are fulfilled. This checklist has also been used for the development of the scenario.

The supported processes are the Connect as well as Plan & Engage phase of the experiment. 21.3

Example

ICT PSP Project Reporting

237

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines Functional requirements Software

Operating Environment Run time dependencies Design time dependencies

Hardware

Use case specific requirements

Use Case 1 Use Case 2

Use Case 3 ICT PSP Project Reporting

A standard distribution of Microsoft XP or Vista operating system is preferred although the platform can also execute on certain distributions of Linux. It is advisable to consult the developers in advance before installing RWIP on Linux. A Java runtime Version 6 is required for execution of the platform. Additionally, OSGi runtime and a backend relational database need to be set up. OSGi runtime files and a Derby database will be packaged with the platform JAR distribution.

For development and configuration of RWIP agents, developers are expected to download and install the 3.4 release of the free Eclipse IDE. Additionally, the IDE should be capable of switching to different perspectives such as Java, XML, JPA, SVN depending on different development needs (thus, the corresponding plugins needs to be installed). Precompiled Java libraries will be provided with the JAR distribution of the platform. Any backend system (for example, an ERP if required for integrating the BAPI service) has to be procured by the consumer SME or partner Living Lab. Standard x 86 compatible processors with at least 1 GB RAM and 2 GB free HDD space is recommended for running the Central Instance and Site Manager. A minimal barebone deployment of the Node Manager with few agents can also run on an embedded PC with 512 MB RAM and hard disk space. Additionally, the manufacturing devices with standard connectivity interfaces have to be procured by the consumer SME.

No specific software other than those specified above. Note that the â&#x20AC;&#x153;assetsâ&#x20AC;? (manufacturing devices) are to be procured by the partners of WP4. For the second use case, wireless location sensors are required. During execution phase of the use case, partners will share knowledge for developing integration agents for these sensors, which may have different technical specifications. Agilion (a supporting partner in APOLLON and wireless sensor manufacturer) will share its expertise during the experimentation phase.

For realization of this use case, Smart Meters have to be procured by the partners. The meters may communicate through 238

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

Non-functional requirements Security requirements

Performance requirements

Resource requirements Skills

Contact persons Activities

RWIP Architecture tutoring Platform deployment

Service development

ICT PSP Project Reporting

the serial port, Bluetooth, or via Wi-Fi and partners are expected to jointly develop integration agents with different technical specifications.

A basic authentication mechanism is provided in the Site Manager component of RWIP. However, an advanced role-based access control and authorization mechanism is not included since security is not amongst the top priorities of the pilot. More sophisticated authentication mechanisms could be developed by the platform providers during the course of the project depending on common requirements from WP4 partners. RWIP is a loosely-coupled implementation of a distributed system and heavily uses asynchronous message-passing. Therefore, the platform is not expected to conform to hard or soft real-time constraints. However, the platform is able to scale to distributed nodes, each connected to multiple devices and guarantees ordered delivery of messages and events. The user of RWIP should acquire the concepts of objects, object types, Site Manager, object oriented hierarchy, and service orchestration through on-site (and remote) tutorials to be provided by SAP Research Center Dresden. Additionally, the agent developers are expected to have advanced knowledge of Java programming language, XML, Eclipse programming environment, OSGi framework, and common device interfaces/protocols. A basic understanding of different manufacturing processes is also recommended. Who are the technical, business, and administrational contacts for each partner?

It is estimated to take around 30 PD for SAP and 20 PD for others. Note that this activity will incur travel costs as partners are expected to participate in hands-on training workshops in Dresden, Germany lasting between 2-3 days each. For deploying the platform at each of the locations, the participants are expected to invest around 30 PD each. This activity will involve development of deployment topology, understanding device connectivity issues, and related troubleshooting activities.

This activity involves breaking down of three use cases into implementable services and developing/deploying/configuring them on RWIP. This activity will take around 60 PD each for 239

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

RWIP development tutoring

eManufacturing pilot

ICT PSP Project Reporting

partners involved in technical development (especially IT SMEs) with 20 PD on average per scenario.

This activity involves tutoring of RWIP service development aspects to advanced technical developers from each location. It is estimated to take around 30 PD for SAP and 20 PD for others. Note that this activity will incur travel costs as partners are expected to participate in hands-on training workshops in Dresden, Germany lasting between 2-3 days each. The most prominent/useful scenario will be chosen for pilot and demonstrated at the eManufacturing workshop in Dresden in November 2010. It is estimated to take around 40 PD for SAP and 30 PD for all other partners.

240

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

22.

Customer review questionnaire

Contributor: SAP 22.1

Problem

This method is valuable in case of the following situations: â&#x20AC;˘

â&#x20AC;˘

Implementation of a product is being conducted / finished at a remote site

Cross border implementation of a product has been planned but not carried out

There should be a sufficient way to evaluate experiences made during the cross border collaboration. By having this information best practices for future endeavors can be decided on and possible problems can be prevented during the early stages of a project.

A joint view at the result is needed. A questionnaire used for all customers will make project outcome and experiences made by different stakeholders comparable. 22.2

Method description

In order to review the gained value as well as the pilot implementation it is needed to get feedback from the user group. The questionnaire has to be prepared based on experiences made so far. There is general information available on how to do a project review in a project management context. Based on this information the questionnaire can be defined specifically for the project.

It has to be decided by project members whether to do a review during the finalization of the product implementation or to also take the questionnaire during the experiment. It is useful to conduct interviews including a moderator in order to complete the questionnaire. 1.3 Use of the method

This method is designed to evaluate whether the goals set for the project could be achieved. If these goals are or are not met, it has to be determined what factors lead to this result.

Results from the Questionnaire are to be used as best practices for further cycles of use case implementations. This method is mainly used during the Manage & Track phase of the experiment. It is dedicated to support all other phases of the Living Lab networking cycle as well.

ICT PSP Project Reporting

241

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

23.

Expertise database

Contributor: SAP 23.1

Problem

This method is valuable in case of the following situations: • • •

You have a service which you would like to offer in another country

You have a product which you would like to offer in another country

(You have a product/service which you want to introduce/test to/at the market and/or a new market)

When implementing an existing product at a further location several new partners are usually involved. It is suitable for these partners to get access to knowledge acquired during previous implementation cycles of the product. Additionally the product provider needs country specific information from the new customer.

Using knowledge/expertise gained during earlier implementations of a product and also using country specific expertise by the new partners/customer should reduce efforts during the Plan & Engage and Support & Govern phases of the experiment. The Living Lab environments have access to numerous partners where expertise can be found, a database is a useful way to document this. 23.2

Method description

The expertise database aims at identifying stakeholders from an environment where the product is in use and to specify their expertise with the product. Having a database will give new customers and their partners the opportunity to get connected to and get supported by experienced partners. Also experienced partners may share their experiences throughout the implementation of the product in their environment as part of the database. The method supports SME involved in the product to collaborate with SMEs abroad. Special focus should be laid on the topics of: • • • • •

Policy regulations

Legal issues

Electrical standards Certificates

Contractors

23.3

Use of the method

A database has to be found which is easily accessible for all partners. Collected experiences should be sorted by categories and contact. The option to use a Wiki for ICT PSP Project Reporting

242

Version 1.0 08/05/2012

D1.4 Recommended Toolset and Collaboration Guidelines

the realization of the database should be checked since the use of Wiki technology could simplify access and usability for users. In order for the database to be useful and up to date it should be required to run a governance process which schedules regular context updates after achieved milestones and/or finishing a pilot or experiment. For the adoption of a product in a new environment there are requirements from the existing product at another site. Therefore possible experiences and obstacles are known already and can be adapted to the new environment supported by collected knowledge from this database.

This method will also be used to adapt the product to different conditions in different countries. Localization of a product can be a substantial task especially considering the software part. Large companies participating in a project have vast experience in localization and there may even be localization teams whose expertise should be used. From the product providerâ&#x20AC;&#x2122;s point of view, previously acquired expertise as well as overcome obstacles will help to rule out problems that may occur while selling and implementing their product in a different country. New customers who will implement the product at their site will then be able to access the database to prepare their business and get in contact with experienced partners abroad.

The database is a tool to further improve cross border collaboration, especially for involved SME. The method is used during the Plan & Engage as well as the Support & Govern phases of the experiment.

There are several knowledge management solutions available, when choosing a tool emphasis has to be on accessibility by numerous different users. 23.4

Experiences

During the implementation of the first use case that had been running in Germany and was to be adopted in Portugal in Work Package 4 numerous mostly legal obstacles had to be overcome. Partners suggested that most of the information needed could have been collected beforehand from similar experiences. Similar problems could be approached in other work packages involving the anticipated database.

ICT PSP Project Reporting

243

Version 1.0 08/05/2012