R&D 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 value accounting system.

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.

R&D projects require a lot of imagination and creativity. They also require physical and virtual spaces, 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, we 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, analysing, etc. We 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 VAS) of R&D to a document, not to a physical thing. Antonio seems 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. We haven’t included Simulation in VAS yet, because we haven't done much, but I 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 value network 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 a revenue, which in turn will be used to sustain the entire value network. This is the use value-oriented, or market-oriented R&D activity within value networks. Excess revenue, which is the difference between what is needed to sustain the value network 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 value network, by maintaining and strengthening relations between members, by fostering a culture which values the creation of new knowledge, the emancipation of humanity, etc...

The value accounting system must acknowledge market-driven and passion-driven R&D. Moreover, the value accounting system is designed to solve the redistribution problem, i.e. it describes a method for the redistribution of revenue generated when concrete and valuable applications resulting from R&D activities are exchanged on the market. In other words, it allows, to a certain degree, to trace back past contributions that made possible the creation of the exchange value. This back-tracing is in essence 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 T. 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 value accounting system must acknowledge this possibility. We can say that passion-driven R&D has 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 have might some perceived market value potential at time T, 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 value system, 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 created 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 value accounting prototype, based on the REA model, values are Economic Resources of different Economic Resource Types. They have a measure of quantity and a measure of 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 income distribution from the live project.

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

Resource flow = value flow.

In other words, value transfer between projects is a resource flow between processes 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 Value Network 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.