R&D projects

Also called development projects.

See larger definition of project

Definition

See Wikipedia's entry on R&D

R&D in relation to OVNi

People expect different things from OVNi based on their own interpretations of R&D. We need to describe how people see R&D in order to design software that is intuitive for everyone. Due to its chaotic nature, R&D caused a lot of problems in designing the first instance of the server-based NRP-CAS application.

R&D projects produce new knowledge and know how. This can lead to prototypes and products through applications development. Prototype are refined or matured into products, which can be exchange on the market for revenue or disseminated as DIY artifacts.

R&D projects require a lot of imagination and creativity. They also require physical and virtual spaces for collaboration, instruments and equipment, skilled individuals, data, information and knowledge management tools. Collaboration and sharing of data, information and knowledge is a must in R&D. Knowledge needs to be formalized and structured.

Some R&D projects can be very market-oriented, others less.

From Sensorica's experience

In the past, Sensoricans have made distinction between activities such as Design and Engineering. Engineering was introduced by Frederic D. to refer to tinkering with material things, assembling, testing, analysis, etc. They introduced Design mainly for Daniel, who at the time was mainly doing 3D modeling and product design. The definition of Design was (if I can represent it correctly): working in a virtual environment to produce a representation of something as a 3D model or a sketch, represented by a drawing, a picture, a 3D file, etc.

R&D is an activity that incorporates Design and Engineering. It is part of product development. Its tangible outputs (captured by the value accounting system) are designs, methods and processes, and prototypes that eventually mature into products. Its intangible outputs may be more increases social cohesion, increased understanding, expertise, know how, reputation,...

Tibi proposed to restrict output (in NRP-CAS) of R&D to a document, not to a physical thing. Antonio seemed to agree with this idea. Even though physical prototypes may be produced, the real goal of the R&D activity is to figure out a reproducible process, a method to make something that works (a prototype, a product). Thus, the output of R&D should be a detailed description of the process/method, not the thing itself. But R&D is more than just Design. It is about a tested design. Therefore, R&D includes Design and Prototyping. Prototyping presupposes not just the making of the designed thing, but also its testing in normal use conditions, and even beyond the normal conditions. We often call this proof-of-concept.

In between Design and Prototyping we can also have Simulation, which is like testing or proof-of-concept but in a virtual environment. For complex and expensive systems many simulations are done before the real prototyping in order to diminish the probability of error and wasting of resources during prototyping and testing. Sensoricans haven’t included Simulation in NRP-CAS yet, because they haven't done much, but they think this should be included.

NOTE: The physical prototype can be destroyed after its testing. The R&D document should be good enough to allow someone to build another functional prototype while avoiding all the pitfalls encountered during the development phase.

On the dynamics of R&D projects

It is important to describe and model the dynamics of R&D projects. The OVN model is designed to be a self-sustainable economic system. Therefore, R&D projects must be first thought in relation to real needs. The end goal is to produce use value and/or exchange value. The exchange value produced by R&D and applications development insures benefits, which can come in the form of revenue, which in turn will be used to sustain the entire network. This is the exchange value-oriented, or market-oriented R&D activity within OVNs. Excess revenue, which is the difference between what is needed to sustain the OVN and the total revenue generated, can be allocated to passion-driven R&D activities. That is important because practical applications of new knowledge are not always evident. It is also important because the development of new knowledge and know how, counterbalanced by wisdom, as well as by sound ethical and normative systems, is the hallmark of human civilization.

We must also acknowledge that R&D activities also create intangible value for the entire network, by maintaining and strengthening relations between affiliates, by fostering a culture which values the creation of new knowledge, the emancipation of humanity, etc...

The NRP-CAS must acknowledge market-driven and passion-driven R&D. Moreover, the NRP-CAS is designed to solve the redistribution problem, i.e. it describes a method for the redistribution of benefits that are generated when concrete and valuable applications resulting from R&D activities are disseminated or exchanged on the market. In other words, it allows, to a certain degree, to trace back past contributions that made possible innovation and production. This back-tracing is in essence a decomposition process. Somehow, the system must contain relations between past R&D activities. It is precisely the system of these relations, which is time-dependent, dynamic, that we are trying to describe in this section.

Market potential

Passion-driven R&D projects, by definition, have no path to market at a time T0. They are not carried out with an application in mind, or the application is not well-defined, or well-articulated. But someone, later, at time T1, can trace a path to market for the knowledge and know how developed in the past by passion-driven R&D. The NRP-CAS must acknowledge this possibility. We can say that passion-driven R&D can have market potential.

Dead end

Some R&D projects are dead ends, i.e. they are built on false premises and are technically not feasible, economically not sustainable... Thus, these projects might have some perceived market value potential at time T0, and no market value potential at a later time, once they are discovered to be dead ends.

Partial recovery

At the first glance, we may say that dead projects should not be accounted by the NRP-CAS, since they don't have a path to the market. But even though their end goal is impossible or non-viable, some value can still be derived during the process. For example, a new method can be discovered during the dead end project or an old method can be refined. Therefore, dead ends must still be documented.

We can try to formalize this situation. Suppose "n" is a recognizable feature of an R&D project, which can be traced in an application or a product. [This definition of "n" is too vague for now, the goal here is to say that R&D projects are heterogeneous entities, made of parts that can be split, mixed... We don't want to say more at this stage]. We can think of an the R&D project as a complex of such recognizable features. Le's suppose a composition law of the form:

nm

where an R&D project is though of as a combination of two recognizable features, at time T.

Suppose an R&D project nmk. A recognizable feature from an R&D project abk, suppose "k", can be recovered or integrated within another R&D project gl, to become kgl.

gl + k --> kgl

Fork

An R&D project nmk can develop/inherit two incompatible recognizable features and split into two R&D projects.

nmk --> nmkl

nmk --> nmkp

Merge

Two separate R&D projects can merge into one. This is also the case when one RND project is totally included into another one.

nmk + dfg --> nmkdfg

[Example from SENSORICA: the transducer project is included into the Mosquito project]

Values, Resources and R&D

In the NRP-CAS prototype, based on the REA model, valuables are Economic Resources of different Economic Resource Types. They have a measure of quantity and an estimated value.

Examples of Economic Resources include a design, prototype, product, a component, a raw material, time spent working, use of equipment and lab space, anything of value that can be identified.

Therefore, an R&D project that was itself a dead end could be incorporated into other projects simply by using any resources from the R&D project in another project. For example, using new methods, using 3D design elements, using LabView programs, whatever. As long as the live project logs the use of the resources from the dead project, the dead project will be included in the benefit distribution from the live project.

No need to merge projects or do anything else but document the resource flows.

Resource flow = flow of valuables.

In other words, resource flow between processes are transfers of valuables between projects where one process belongs to one project and the other process belongs to another project.

Praxis

Sensorica's way to log R&D work

NOTE: This section requires serious cleanup, because the system have evolved!! Tibi

Below is a tutorial about the first implementation of R&D projects in the server-based NRP-CAS software. It will most certainly require great changes, some of which are suggested in the tutorial.

On the Demand page, click the "Create R&D Project" button:

You will go to this very large form:

The form has three sections, outlined in red.

On the left: the details of the R&D process. The Recipient and Provider are optional. They might be something like Recipient: Maksim, Provider: SENSORICA.

On the right: the outputs from the process, and the inputs to the process.

You may have many outputs as well as many inputs. You may click the + buttons alongside the Resource Type selectors to create new Resource Types.

Pretty soon, this form will have a "Save and continue editing" button that will allow you to add more outputs and inputs than the slots provided on the initial form.

But for now, when you click "Save", you will go to a page showing the details of the R&D process. From there, you can click the "Change" button to add more outputs and inputs.

You may also create other processes that are related to the new R&D project, by going to the Work page, and clicking the "Create a new process" button.

When you click that button, you will go to a form that is similar to the "Create R&D Project" form, but allows you to select an R&D project that the new process is related to.

As the form says, selecting an R&D project is optional. You can also create standalone processes that are not related to anything else. Or you can relate them later.

To connect the related processes, use the output from the related process as an input to the R&D process. You do that (for now) by going to the R&D process page and clicking the "Change" button.

Which will take you to the form to change the R&D process, where you can add the output of the related process as an input.

This works, but could be easier, because you need to go looking for the related output Resource Type. (Bob says: pretty soon, I will create something better to link up related R&D processes, and update this tutorial.) (And note: if you add an input to the "parent" R&D process, and then create a feeder process to make it and specify the parent R&D process in the "for R&D process" field, they will automatically be connected, and you will not need to go through that whole rigamarole.)

But for now, here's the related process linked up:

Note: This is also an example of linking ideas or other design inputs to R&D and other processes.

Contributing to the R&D processes is exactly the same as contributing to any other process, as in this tutorial. The work requirements for the R&D processes will appear on the Work page, where you can Take unassigned tasks and document your work in Labnotes pages.