Home > Praxis > Design and development > Methods for participatory project development

Practice

Methods for participatory project development

Challenge: Economy

Participatory methods play an increasingly important role in digital development processes used by the for-profit sector. As a general rule of thumb, the more users involved in development, the better the results and products. Given that DC/IC commonly involves participation, and methods like co-creation, design thinking and scrum are relevant in its work. Applying these methods can help secure ‘ownership’ of digital technologies.

When weighing between the various participatory methods used in DC and new approaches from the for-profit digital sector to decide which are relevant, make sure you consider the following:

  • Co-creation, design thinking and scrum are ideal for technical and financial cooperation projects and programmes, but they require at least a medium-term commitment if they are to be successful.
  • When deployed one-off in individual workshops, these methodologies are likely to be only partially successful. In cases where a methodology is to be used, it should therefore be assessed whether the methodology can be deployed in a targeted manner throughout the entire project.
  • The process should be viewed in terms of the ultimate objective. What users/user groups will you be working with? What intermediate results are needed? • These methods are based on time-consuming, labour-intensive processes.
  • Applying these methods to the often-linear logic of DC/IC with its fixed tar gets can be challenging, because they are based on agile planning processes and have been developed for open-ended processes. Participatory project components with qualitative targets and indicators are therefore especially suitable for testing these methods.
  • The commissioning party should be prepared to be one of many stakeholders involved in the process, given that target groups will be actively involved in project development and make a decisive contribution to results.

Co-creation

Co-creation brings different parties together to collaborate on achieving a positive and useful outcome for all participants. The co-creation process is iterative, encouraging teams to loop back to previous stages to refine their work. A key feature is that it involves the target group in the development phase. As a result of their cooperation, users are much more likely to end up with a product they actually need.

  • Objective: To jointly develop a solution.
  • Central feature: Collaboration.
  • Other features of the method: Dialogue, discovery and feedback.

 

Requirements

  • Possibility of an open-ended process.
  • The commissioning party may assume the role of one of many stakeholders in the development process.

An integrated co-creation approach is based on many steps, which can range from researching a specific workshop design

 

Further information

Design Thinking (DT)

With its origins in architectural design practices, design thinking (DT) has been further developed by Stanford University into a multidisciplinary ap proach for developing products, services and concepts for different contexts. DT combines creative thinking and design processes with methods used in technology and industry. Among other things, it focuses on enabling new forms of cooperation and prioritising user needs. As such, the application of design thinking may, in general, be considered as an approach for manag ing transformation processes in DC/IC. The development of new initiatives involving digital technologies may provide the impetus. • Objective: To develop integrated and user-based solutions to problems, and to promote innovation. • Central feature: Problems are tackled collaboratively and intensely, and solutions are identified as early as possible in the form of prototypes.

 

Four principles that underpin a DT process

1) The process is iterative (repetitive) The development process will include several iterations in order to refine the solution. An iteration normally comprises six steps:

  • identify the problem,
  • observe the problem,
  • adopt a stance,
  • develop solutions/ideas,
  • develop prototypes, and refine them.

 

2) Complying with the rules These rules include, for example,

  • participants always carry out work visually,
  • only one person speaks at a time,
  • allow far-fetched ideas,
  • avoid criticism,
  • quantity is produced (so that you have a choice),
  • stay ‘on-topic’,
  • build upon each other’s ideas.

 

3) Interdisciplinary teams

People from different disciplines are required to work together.

 

4) Alternative and varied workspaces and ways of working

Stay mobile – people may work standing up, ideas and thoughts may be written on whiteboards, etc.

 

Further information

Scrum

‘Scrum’ is a process framework originally intended for the development and maintenance of complex IT projects and products. The term ‘scrum’ is derived from rugby. It describes an interlocked cluster of players. Like design thinking, scrum is an agile process management method1 that assumes that IT projects are often too complex for all their components to be defined at the outset.

Agile process management methods are the counterpart to the waterfall model, which is usually applied in IC/DC. Waterfall process management is characterised by clearly defined, sequential work steps. In agile process management, iterative methods are embedded, which means process sections are partly repeated or steps skipped. In large tenders with clearly defined goals and intermediate steps, it can be a challenge to integrate agile process management. Establishing target figures and time frames or applying agile process management for clearly delineated, definable work steps is recommended.

‘As a method, scrum accepts that the development process cannot be predict ed. The product is the best possible software taking the costs, functions, time and quality into account.’ (Ken Schwaber in a lecture at the 1995 OOPSLA conference) Scrum is suitable for teams of three to nine members. The work process is divided into events (e.g. development ‘sprints’ or review meetings) and artefacts (i.e. minutes or task lists). The process sets out clearly defined roles (from ‘scrum master’ and ‘development team member’ to ‘product owner’ – the owner of the end product).

Objective: The division of a complex and extensive development process into small sub-projects tasked with achieving the best possible results and taking costs, time, quality and functions into account.

Central feature: Precise objectives; the way of moving towards these is defined by the implementation process itself. New developments are constantly taken into consideration.

 

Scrum is based on three principles

  1. The process must always be transparent for all participants (‘transparency’).
  2. Results are constantly reviewed and questioned/inspected (‘inspection’).
  3. Results are constantly adapted and improved according to ‘review’ (‘adaptation’).

 

The process consists of four types of events

Sprint

A sprint is an intense period of project work that can last from one to four weeks. At the start of the sprint, a clear goal and strict time frame are set, neither of which can be changed during the process. The result is what you manage to create within the established time frame. The sprint leads on to the sprint review and sprint retrospective.

Daily Scrum

The daily scrum is a 15-minute meeting held once a day with the develop ment team, scrum master and product owner, and serves as a regular forum for rapidly exchanging information. If questions are not answered within the 15-minute time frame, they are carried over to the next day.

Sprint Review

At the end of the sprint, the development team’s work results are reviewed with the product owner. If a new sprint is deemed necessary, the adaptations required for the process must be agreed upon.

Sprint Retrospective

A sprint retrospective is a self-reflection process. Guided by the scrum master, the development team examines its working methods in terms of efficiency, accuracy and so on, according to the findings of the sprint review. The retro spective is used to update the ‘product backlog’, a list of outstanding action items.

 

Further information

This site uses cookies to provide you with the best user experience. If you like to know more about it or change your cookie settings, please click here