The OP-OD method is based on breaking down a design task into many smaller sub-tasks. Tasks are referred to as ‘calls’. Although OP-OD is not a competitive procedure, the calls are similar in structure to tiny competition calls. They formulate a task precisely. The fundamentals needed to fullfil the task, such as a basic set of plans, legal conditions and standards, already known restrictions, and content requirements, are provided to the participants. Submission requirements regarding plans and documents are also described in a call. Participants prepare their contributions within a clearly specified time frame. In the OP-OD method, these contributions are referred to as ideas or clues. The participants thus take on the role of idea contributors. The calls are published on the digital project platform. They are available in two versions: in technical language and in plain language.

The OP-OD method divides planning processes into several project stages. The starting point of each phase is the simultaneous publication of several, but thematically independent calls. Together, these constitute a call round. The sum of all the calls in a call round defines the thematic orientation and the content-related goal of the project stage concerned. For example, the first application of the OP-OD method entailed dividing the planning task into three project stages — hence three call rounds (see Chart p. XX). Within each call round, three calls were published and worked out.

Each project stage in a project following the OP-OD method is divided into two essential phases: the idea phase and the development phase. The idea phase in each project stage takes place before the development phase. Each project stage starts with a call round (see above).

The idea phase refers to that part of each project stage during which all participants work in parallel — either individually or in small teams — on the issues listed by the calls. It collects and develops numerous proposed solutions (= ideas) for the sub-questions and sub-elements of the project that have been precisely defined in the calls. Participants upload these to the OP-OD project platform for everyone to see. During the idea phase, all stakeholders assume the role of idea contributors. Proposals may be produced and visualised in various presentation formats and media, depending on the participant’s abilities and qualifications.

The term ‘idea contributor’ refers to an OP-OD planning process participant, regardless of their professional orientation. Users or neighbours who submit at least one idea during the planning process are also idea contributors. In turn, the sum total of all ‘idea contributors’ is referred to as the collective of all persons who actively participate in a planning process using the OP-OD method. The objective is to involve as many representatives of all project-relevant interest groups (= stakeholders) as possible. The idea contributors’ group is characterised by its diversity; in addition to users and representatives of building owners, it also consists of numerous specialists from various fields. These include planners from architecture, landscape architecture, technology, sustainability, and accessibility, as well as experts from other disciplines, such as social and sociological fields, if needed. Neighbours and representatives of public interest groups are also represented, whereby each group can and should be represented by several persons. The task of the idea contributors is to deal with the various call issues raised in the context of an OP-OD process by developing and uploading individual ideas. All idea contributors — regardless of their professional or personal backgrounds — are entitled, and called upon to develop and formulate independent ideas. The role of the idea contributors is based on the principle of independent work on sub-questions of an overall project. This implies a low level of coordination with the collective of participants and a high level of self-organisation.

The multitude of ideas and clues developed by idea contributors and uploaded to the project platform generates, and fills up, the so-called ‘pool of ideas’. As a result of the varied, individual perspectives of idea contributors, it contains a wide range of conceptions, points of view, and attitudes. The diversity (or polyphony) of the idea pool constitutes the foundation for the teamwork of the developers during the relevant development phase.

In each call round or idea phase, during which several call issues are always worked out in parallel, it is necessary to effectively organise the capacities and work efforts of the entire collective. This is achieved by issuing so-called ‘idea tickets’, which are assigned to each call question. Their distribution is based on a forecast of the anticipated and aimed-for pool of ideas. This forecast is prepared by taking into account the number of participants and the available fee budget. The expected pool of ideas is then divided into corresponding quotas. These are known to all idea contributors. On the project platform, idea contributors can specify which tickets they would prefer to process and, thereby, set priorities. At the beginning of each idea phase, it is then clear who will work on which ticket. This system enables automated agreement within the collective and, at the same time, ensures clear coordination.

In an OP-OD planning process, ideas are remunerated through so-called ‘idea allowances’. These allowances are determined on the basis of a pre-calculated quota of ideas in alignment with the available fee budget for the project itself. It makes sense to distinguish between elaborate ideas and less far-reaching clues, whereby the former receive a higher reward and the latter a correspondingly lower one. The minimum idea fee should be set at the beginning of an OP-OD process or at the time of the tender. It must be known to all participants. Its absolute amount should be proportionate to the expected average time required. (This demand could not be fulfilled during the first application — see section on real fictions.) One also needs to clearly define which participants may receive an idea allowance. For example, it must be decided whether users or representatives of public authorities will also receive an allowance. However, building owners’ representatives do not need to be rewarded with idea allowances, since they usually receive a fixed salary. As regards users, this can be decided on a case-by-case basis. For instance, members of an assembly which, as the case may be, consists of well-off, well-educated professionals are to be treated differently from a group of people living in precarious conditions. It is, therefore, important to examine each individual case.

Eine Ideenbiografie zeichnet den Verlauf einer oder mehrerer Ideen durch den Planungsprozess eines Projektes mit der Methode OP-OD nach. Sie ist aber derzeit noch kein eigentliches oder gar (durch die digitale Projektplattform) automatisch erzeugtes Werkzeug oder Ergebnis der Methode. Sie muss derzeit noch manuell erstellt werden. Sie dient eher im Rückblick und für die Forschung der Frage nach der Wirksamkeit oder Nicht-Wirksamkeit von Ideen. Ideenbiographien zeigen auf, welche Ideen zu welcher Zeit entstanden und in den unterschiedlichen Synthesen Niederschlag fanden. Auch lässt sich anhand von Ideenbiografien der Einfluss einer Idee auf die jeweilige Synthese, aber auch auf andere darauf aufbauende Ideen oder von ihr inspirierten Ideen zurückverfolgen. Im ersten Anwendungsfall der Methode OP-OD wurden stets die in den unterschiedlichen Synthesen und Syntheseständen verwendeten Ideen im entsprechenden Deckblatt eines Plansatzes mit angegeben. Perspektivisch gesehen wäre es aber interessant, wenn die digitale Plattform die Rückverfolgung von Ideen selbst aufzeichnen könnte. Einzig eine Verlagerung der eigentlich kollektiven Planungsleistung, die das Ziel der Methode OP-OD ist, hin zu einer sehr starken Betonung der Autor*innenschaft einzelner an einzelnen, erfolgreichen Ideen ist hier abzuwägen. Gleichzeitig zeigen exemplarische Ideenbiografien aus dem Projekt metso`metso, dass – selbst im Falle von prägenden Ideen – die kollektive Leistung durch deren sukzessive Transformation im Laufe der Entwicklungsphasen und der weiteren Ideenphasen sogar eher betont als relativiert wird. Man wird aber sehen, wie sich dies in weiteren Anwendungen der Methode OP-OD darstellen wird.

Each development phase rests on the results of the relevant idea phase: the ideas and clues found in the idea pool are viewed, sorted, selected, put in relation to each other and, finally, further worked out by the developers. In contrast to the idea phase, the development phase is always about the interaction between several topics and many elements of the design task, and about the search for a comprehensive architectural solution. With each further project stage, more and more elements and ideas come into the pool and, thus, into the planning-related negotiation and processing within the corresponding development phase. In addition, each development phase builds on the outputs of the previous project stage — expanded with the new call issues and their related ideas. During early project stages, the outputs (= syntheses, see below) of the development phase therefore do not yet amount to a complete design; hence they are still to be viewed, at least in part, as fragmentary solutions. At the end of the final development phase, however, a consistent design should emerge. In the course of each development phase, it is in principle possible to put earlier results to the test again and modify them.

In an OP-OD process, developers are recruited from the overall idea contributors collective. They are chosen either by the collective as a whole, or by specific sub-groups of the collective, for instance planners from the field of architecture or other disciplines, or by the user group, either through a (secret) ballot or another selection procedure. The developers group consists of about eight to twelve people. It is composed of representatives of the stakeholders who are key to the project, including building owners, users, architects, planners from technical disciplines, other experts, neighbours and, if necessary, representatives of public interest groups. Owing to the allocation of work during the development phase and the need to take action in planning terms, it is usually necessary that for a task in, for example, the structural engineering sector, several representatives from the architecture planners group should participate in the development phase at the same time. Within a short period of only a few weeks, these developers, who act on behalf of all the idea contributors involved, work together intensively and full-time as a collective. They gradually develop the design of the house or of the planning task. The task of the developers is to sort, test, synthesise, and consolidate individual solutions collected in the pool of ideas into first (and, then, subsequent) intermediate planning results (= syntheses). They take essential decisions by mutual consent [Konsent]. They are not bound to the idea contributors group by any instructions. Each developer has a free brief.

The idea backpack is a key methodological component of OP-OD development phases. At the beginning of each development phase, all developers ‘pack’ an idea backpack according to certain project-specific stipulations. The backpack is a pre-structured tool on the digital platform. This process involves participants looking at, and assessing all uploaded call ideas. Each developer thus selects the ideas that they consider the most interesting, relevant, and promising and packs them into their own idea backpack. Each developer then presents their selection or decision. This results in initial, substantive mutual exchanges between all developers on the advantages or disadvantages, potential, and synergies of the submitted ideas. Building on this, the entire developer team then collectively packs one or more collective idea backpacks. This is to be understood as an essential, collective participatory negotiation process with regard to the values and demands of the design. Idea backpacks are documented on the digital project platform and anyone can view them at any time. The ideas they contain can also be traced back. As the sum total of the ideas contained in it, each collective idea backpack forms a first (or, later on during the process, a fuller) version of the design.

A synthesis during the processing of a design task using the OP-OD method always entails a combination, in planning terms, of individual ideas and clues that were generated during the idea phases. In contrast to the idea backpack (or idea bundle), however, in a synthesis individual ideas are no longer simply placed unchanged next to each other: they have already been combined into a whole. Usually, they have been adjusted to each other and thus slightly modified. However, a synthesis will not yet necessarily constitute a completed or thorough design sketch that is fully consistent or devoid of contradictions. During the development phase process, syntheses are created immediately after the idea backpacks. Hence, as a rule, first syntheses are always available halfway through the development phase and can be discussed during developer group negotiations. The output of each development phase is also referred to as a synthesis in OP-OD, all the way to the final output of the overall process. Hence every overall design is ultimately a synthesis, but conversely not every synthesis is an overall design. The ‘completed’ syntheses in each development phase serve as a groundwork for each further project stage. They are returned to the idea contributor as preliminary planning results. Any further call questions will then be based on them, even if new calls also raise completely new project issues that have not yet been dealt with. This is possible because syntheses serve as open preliminary results that might still undergo significant changes later on in the process. Yet the negotiations and decisions reached through agreement by the developers and incorporated into them should not lightly be disallowed.

Each synthesis that is returned to the idea contributors at the end of one development phase and the start of the next idea phase contains a so-called package insert. The developers can explain important elements of the synthesis from their points of view, list open questions, or investigations still deemed necessary, or more in-depth planning needs but, also, ask direct questions to the idea contributors. In addition, each synthesis is also accompanied by a list of the ideas used or taken into account in it.

An idea review is a tool that should be mandatory midpoint in every development phase, but can also be used again and again. The basis of an idea review are the preliminary planning results achieved in the course of the development phase, i.e. a first synthesis. The synthesis is examined with regard to its problems and open questions and, if necessary, also discussed. Aided by this knowledge, the developers review the entire idea pool once again and examine whether a problem-solving approach to the open questions of the synthesis can be found in one of the ideas not previously considered or applied or, even, whether whole ideas in a synthesis should be swapped in favour of others. The idea review thus serves as an iterative loop in the collective design process. In addition, the OP-OD method seeks to ensure that no ideas are overlooked and, above all, that the linking of the developers’ work with the idea contributors’ work is as profound as possible in the sense of joint authorship.

The developers receive remuneration in the form of daily rates that are the same for all parties involved. These rates are irrespective of their particular qualifications. The daily rate should correspond to a full-time freelance income (excluding VAT). At the beginning of a planning project, a distribution key will be specified, which defines how much time each person involved will spend per development phase. This key is intended to reflect the expected workload of the various contributors. Development teams, however, are free to redistribute the daily rates amongst themselves. Thus, for example, an architecture planner will receive ten daily fees for a two-week development phase, while a technical discipline planner might receive only five daily fees. In this way, the workload can be mapped, whereby the work of each individual is of equal value.
In any case, assistance provided by users or neighbours should also be remunerated at the same daily rate. This should make the participation of all social groups affordable. The building owners’ representatives, on the other hand, usually do not receive any fee in the form of a daily development rate, since these persons receive a fixed salary for their work anyway. In individual cases of building owners involved on a voluntary basis, however, this may be understood differently.

The architecture team consists of those architects who have been appointed by the collective (usually the architecture planners) by (secret) ballot to move the planning forward, in the wake of the actual collective planning process, on behalf of the entire group and within an agreed framework to the more advanced service phases of the HOAI [German ordinance regulating the fees for architectural and engineering services]. However, this procedure is not yet feasible for public planning tasks (see Thresholds).

In all phases of a planning process using the OP-OD method, participants receive an allowance that should correspond to the assistance provided (see idea allowance and development daily rate). The usual prize money in a conventional competition, as well as the processing fees for the planning phases to be provided through the OP-OD method (such as Service Phases 2 and 3 according to HOAI) are added up to a single sum. This sum should be distributed fairly in alignment with the number of participants (idea contributors), development phases, and developers. To ensure that no one is underpaid, adjustment is carried out in reverse precisely thanks to these ‘setscrews’: the number of idea contributors or idea tickets (see above) and the number of development phases and developers.

The OP-OD method has been developed and is being applied as an open source method. It is inspired by ideas from the software development field. In that field, the approach is about creating products whose source code is publicly accessible. This can be modified and distributed at will by any person. Such products are then released under an open source license. This means that the source code is visible to all users and can be further modified by them. Open source products, whether in software development or other sectors, are developed in a decentralised and collaborative manner, and are based on the principles of peer review and community production. The OP-OD method also strives for free applicability and adaptability, albeit on a slightly smaller scale or involving less complexity. It is explained in the digital guide available at www.op-od.de. Individual modules can be transferred and adapted to one’s own projects, which makes a decentralised application possible. In this way, continuous further development of the method by the community of all users and interested parties can take place. In this regard, no medium or method for this reverse process has been defined yet.

Scrum is a framework model. It organises team collaboration for the processing of tasks, primarily in software development. Scrum defines specific roles, meeting arrangements, and tools that enable a structured, clearly defined work process underpinned by agile principles. The basic terminology and role of developers in OP-OD suggest a loose analogy to Scrum. The method emphasises agility in project management, which is achieved through an iterative, incremental way of working. A Scrum project begins with the formulation of a clear objective in a complex subject area where it is difficult to plan ahead. Scrum is characterised by few, simple rules; the self-organisation of the team takes centre stage. The only fixed element is the project objective. A project is divided into phases in advance and the team is provided with certain methodological tools to carry out the work and check it. For example, the project objective is divided into smaller work packages that are controlled through tickets, and progress is recorded in a burndown chart. The efficiency of the methodological approach plays a crucial role. Several building blocks of the Scrum method served as fundamental inspiration in the development of OP-OD, but were reinterpreted. When wrestling with the Scrum method, it was found that its process modules could not be directly transferred to the architectural planning process. The OP-OD method differs significantly from the Scrum method in many key aspects. For example, it borrows at least as much from (open) competition procedures and classic participation models in architecture as it does from Scrum. On the whole, the OP-OD method is therefore a stand-alone symbiosis of many distinct elements.

A digital platform is an essential part of a planning process using the OP-OD method. It enables a decentralised, effective, free organisation of both the collective and the process. The specific project platform acts as a vital anchor for the process, successively recording and documenting the following: all basic project information; the content and time structure; all issues raised in the calls; the distribution of call tickets; detailed project steps; all appointments; the various organisational units (such as the idea contributors collective and the development teams); all role profiles; all elections and votes; as well as all ideas, syntheses, and the final result. All of the above can be consulted by the participants. The platform, currently only available as a working prototype, also already offers a few embedded tools specific to OP-OD, for example for packing idea backpacks and for idea reviews. The extent to which the platform should also provide further options for communication and comment will depend on the individual requirements of a specific project.

Text folgt