SME-Driven Research through Collaborative R&D - the PRiMa-Q Project

SMEs are the main drivers in many economies worldwide, especially in European countries where they hire around two thirds of the people and generate 58% of the total value added. However SME usually lack resources both in time and expertise to perform enough R&D in order to stay up-to-date in a world evolving at fast pace. This is especially true for ICT which is now required in all domains for successful operation, e.g. industry 4.0, logistics, eHealth, energy, etc

CORNET is a network of ministries and funding agencies that combine their existing funding schemes to increase the competitiveness of SMEs. In this blog we report about how we came up with a practical organisation of such projects to efficiently support SME needs and transfer results. We try to provide some answers to the following questions :

• how to manage the project using an iterative (Agile-inspired) approach, given the need to gather requirements, develop a practical solution and validate it within a short (2 years) time frame.
• how to efficiently gather the requirements through different means such as interviews with companies and online survey.
• how to build a common vision of both the problem and the solution using adequate techniques such as models and scenarios.
• how to manage the prototyping and validation within the short project duration and in order to maximise the chance of exploitation.

Our experience is mainly based on two CORNET projects (3 R&D partners and about 10 SMEs) and also CWALITY projects (CETIC+SME). In the scope of this paper we will take the project PRiMa-Q addressing the need for a risk-driven project management. We selected this project because its focus is precisely related to project management and to some extend the project itself is a case study. In general SME face many problems that can cause failures, delays or budget overruns in their projects. Such problems are not restricted to SMEs, but they can be very harmful or even fatal for them due to their limited size, maturity or resources. Project management is especially recognised as a vital part in the IT sector where about half of the projects are challenged and 20% still end in failure. This problem tends to extend to all domains because most products and services are increasingly connected and relying on the Internet of Things. The production process is also increasingly dependent on IT through the use of smart manufacturing.

Adopting an Iterative (Agile-Inspired) Approach

In order to stay focused on the SME needs within a relatively short (2 year) project, following an iterative approach is strongly recommended. Agile principles and their four core values are totally aligned with SME needs and can drive the project:

• focus on people and interactions rather than on process and tools.
• target working software rather than exhaustive documentation.
• collaborate with customer rather than stick to a contractual relationship.
• adapt to changes rather than blindly following a plan.

Those values are further refined into 12 principles. Those principles are implemented in specific concrete methods such as Scrum (illustrated in the following picture), extreme programming (XP), behavioural driven programming (BDD). However such methods should not be blindly applied to R&D projects because the timing, level of resource allocation, target TRL is different than pure development projects. However key principles such as focusing on needs, validating early, adapt to change apply.

Scrum Agile process.

Our goal here is not to point to a specific method but rather to highlight a number of concrete actions which can be implemented in the scope of a short term R&D project. In the rest of this section we describe how the main concepts were implemented for our project and can inspire other projects of the same kind.

• Project (backlog) initialisation. At the beginning of the project there is a typical phase where partners have to learn to know each other, set-up the project organisation, collect requirements with end-users and agree on the initial project scope. This can typically last from one to six months. During that time, however, some technical developments related to the required project infrastructure can progress in parallel.
• Iteration duration. In commercial development, sprints are usually 1 or 2 weeks long. In a typical R\&D context, the teams needs longer time to achieve specific units of work because projects are often intertwined with a number of more operational and shorter term tasks which are indirectly feeding the research (like technology transfer, publication). A typical iteration will last between 1 month to 3 months depending on the project. As the project progresses, less research and more development is likely to occur, making the project closer to a classical development. At that time, the project will also focus on delivering a well-defined demonstrator. This generally results in shorted sprints towards the project end.
• Standups can focus on a single partner or a subset of partners involved in a specific task. In our case, "stand-up" meetings are actually short 1 hour meetings that are held on a weekly basis at a dedicated time slot. In addition, a teleconference is also organised to synchronise with the other partners, typically on a bi-weekly basis.
• Iteration debriefs can occur in longer teleconferences and at the occasion of physical project meetings between partners and/or end-users. Such meetings are typically held every 3 months to 6 months at the longest (in our case it is required for administrative reasons). A good idea is to mix the type of meetings, one with the local user committee for a given sprint and the other one with partners of the upcoming/next sprint. Meetings with the user committee will ensure the final users are kept in the loop to make sure with them the project is addressing their needs and delivering value to them. The meetings with partners are also important to ensure the agreement on the objectives and planning for the next sprints.

Gathering Realistic Requirements

As most SMEs oriented projects, our project is quite short (2 years). For such a project it is important to avoid ambitious breakthrough but rather focusing on concrete objectives delivering value to SMEs that are quickly identified and agreed upon. Ideally, those objectives should already be stated in the proposal, as it is part of the reviewer criteria for such a project. However, in order to refine the requirements, a dedicated task is generally proposed in the first month of the project (see initialisation phase here above). Different means can be used to achieve an efficient gathering of requirements, in our case we used meetings with end-users, an on-line survey and extra refinement of the state of the art.

Meetings with end-users

A CORNET project has a mandatory end-user committee. The first meeting will generally focus on explaining the project goals to the SMEs representatives and identifying requirements with them. It is important to gather requirements that can be generalised in order to have a good exploitation potential but also to identify a number of concrete use cases that will drive a concrete validation. For this purpose, different techniques can be used like looking at existing systems from users, an organising brainstorming session, collecting user stories, etc.

Performing an Online Survey

In order to gather requirements at a larger scale than the user directly involved in the project, it is useful to design an online survey which should not be too long to fill. It should typically take 10 to 15 minutes and avoid too complex questions which will result in user leaving the survey. It can be first used with users already contacted in order to make sure it is well-designed before disseminating it at a larger scale using different channels and relays like sector specific organisation, professional social networks, and special interest groups. Such a survey should gather some information to characterise the respondent, current practices and identify/validate requirements through closed but also some open questions (not too many). Although by default such a survey should be anonymous, it can nevertheless propose to the respondent which is quite interested in the project to provide a contact to be informed by project progress or even to join the user committee. An example of survey question is shown in the following figure together with the analysis done on the collected answers.

Online survey

Being "State of the Art"

A state of the art is usually already available as part of elaborating the project proposal. However, such a state of the art usually needs to be refined in order to better consolidate it, to cope with possible evolution since the writing of the proposal and most importantly to adapt to the more concrete input provided by the requirements analysis phase. In our case it was important to have a clear view of both existing project management tools and risk management tools. Specific criteria were identified with SMEs like cost, integration usability issues. Among the involved SMEs there are some software editors and naturally their tools are taken into account in this update. For example, the figure hereafter shows the resulting evaluation table for the key non-functional requirements identified as a result of the requirements phase and a short list of existing tools also validated by the partners as possible target tools.

Non-functional requirements for tool selection.

Building a Common Vision

In order to build a common vision that will drive the project towards a solution, different means can be used. In addition to good collaborative infrastructures like Redmine, we highlight two interesting means with the related notations: building a (meta-)model of the concept (covering both problem and solution aspects) and defining a reference architecture of the solution.

First a meta-model is quite interesting to use for the following reasons:

• it relies on a simple set of notations that can help sharing a common understanding of a domain across all R&D partners and also end-user SMEs
• elaborating a meta-model from scratch can also be a good exercise but at some point, it should be confronted with meta-models elaborated by others and published in the literature. This enables to check if the generic model is good enough and in this case it is better to stick to a standard and already recognised work rather than trying to reinvent the wheel.
• the meta-model can be further refined in many implementation artefacts such as a database schema, an API, a report template, etc. It will also ensure a global consistency and enable to track evolutions when required. The following figure shows a simple meta-model combining both project and risk dimensions as required by the PRiMa-Q project. It is structured around the central notion of goal.

PRIMa-Q meta-model.

Second it is important to define a reference architecture. There are different complementary goals behind the definition of such architecture such as:

• defining a minimal solution that can be prototyped within the project duration and deployed in collaboration with some participating SMEs. This means the solution should not be too complex and should focus on a core of mandatory functions. It should also be quite open especially with the kind of interface required for achieving the required integration within the project in order to validate the concept on a company use case.
• building a simple solution that can showcase the proposed approach and that is easy to try and adopt. This means the proposed solution should not be overly complex and also rely on freely available (even preferably Open Source) technology. Moreover the solution should rely on mature enough component to be convincing in terms of usability and performance.
• defining a generic enough solution with good potential of exploitation, i.e. the solution should be able to evolve beyond the end of the project or to integrate in more complex environment, including possible commercial solutions used in the field. Again this calls for a quite open architecture.

Conclusions

Successfully addressing SME needs within a 2 year R&D project is quite challenging. We hope the guidelines can guide others to reach similar goals and also encourage SMEs to engage in projects of the CORNET program or other SME-oriented R&D programs like CWALITY. Don’t hesitate to contact us for more information.