Democratic dialogue: advice common to the entire IT project

Contents

This page contains a set of APIDOR recommendations that apply to the entire project or to several phases of the project.

It addresses the role of democratic dialogue in IT projects, project stakeholders and bodies (committees), key points for conducting democratic dialogue during the project, the categories used during the project (users, ENF, etc.), the project management system and project timeline, and organisational learning.

A table of categories of requirements (needs) in terms of well-being and citizenship at work, as well as concrete proposals for needs, can be downloaded here.

Summary

The role of democratic dialogue in IT projects

Stakeholders and bodies (committees)

Key points for conducting democratic dialogue

Categories used during the project (users, NFR, etc.), examples of well-being and citizenship needs at work

Project steering system

Project time, organisational learning

Place of democratic dialogue in the IT project

Involvement of top management

Top management has an essential role to play in introducing and promoting democratic dialogue in the project.

The introduction of democratic dialogue in IT projects must form part of the organisation’s high-level objectives, or even its strategy.

A central objective of the project must be that the application developed does not generate “social debt” (see The debts that can be generated by an IT project).

This presupposes that certain dogmas are challenged, including :

• the equivalence between speed and efficiency
  • …which can be expressed in the idea that democratic dialogue wastes time in an IT project
  • …and which will be reinforced by project monitoring indicators focused exclusively on costs (generally considered to be too short-term), and on schedule monitoring.
• the dogma of complexity, which means relying on the word of the experts¹ , thus generating the risk of dialogue being pre-empted by the experts
• the “natural” character of categories or indicators, which would make them escape the dialogue…

Information at the start of the project on the democratic dialogue

At the start of the project, all the players involved must be informed of:

• the decision to introduce democratic dialogue into the project,
  • so that the issues of well-being and citizenship at work are taken into account in the software to be developed
• the objectives pursued by the democratic dialogue within the project
  • and the measurement of their achievement
• the practical arrangements for democratic dialogue on these issues.

As far as possible, a consensus or at least the consent² of all stakeholders should be sought.

Stakeholders and bodies (committees)

All the players and bodies involved in the project have a role to play in the democratic dialogue on well-being and citizenship at work.

However, certain players will have a more essential role and will also be more focused on these issues.

Project Owner (PO) and specialised project owner assistant (POA)

In particular, it is conceivable that the PO will not only be responsible for the ‘business’ aspects in the functional sense, but that he will also be in charge of the aspects of well-being and citizenship at work, which essentially correspond to the concrete, real conditions in which the operators carry out the business tasks and the meaning that these tasks have for them.

Similarly, it would certainly be useful for there to be one or more PO assistants in the organisation who specialise in holding a democratic dialogue on the issues of well-being and citizenship at work.

Acteurs métier porteurs des demandes en matière de bien-être et de citoyenneté au travail

Certains acteurs « métier », futurs utilisateurs de l’application, pourront se révéler plus aptes à porter les besoins de leurs collègues sur ces thématiques, et pourront être chargés de les représenter.

Ces acteurs « représentants des utilisateurs » doivent être reconnus comme des membres à part entière, des parties constituantes du projet, et notamment être destinataires des informations partagées dans le projet.

Ils seront un appui à la MOA sur les questions de bien-être et de citoyenneté au travail.
Ils pourront faire partie de certains comités : comité de projet, comité utilisateurs, et de l’instance spécifique si elle est créée.

Business players who are the bearers of demands in terms of well-being and citizenship at work

Certain “business” players, future users of the application, may prove to be better able to convey the needs of their colleagues on these issues, and could be tasked with representing them.

These “user representatives” must be recognised as full members of the project, and in particular as recipients of the information shared in the project.

They will support the project owner on issues of well-being and citizenship at work.

They can be members of certain committees: the project committee, the user committee, and the specific body if one is created (see Specific body)

Representation of the CSE

If the IT project is likely to have an impact on the company’s objectives, its strategy or, more generally, exceed a certain estimated cost, a representative of the company’s social and economic committee may be involved in the project, either as a whole or during certain essential phases (e.g. initiation phase).

Specific body?

A specific body may be envisaged to formalise, validate and check that the needs expressed in terms of well-being and citizenship at work are taken into account.

Such a body should be made up mainly of future users of the application and people who will be impacted by it, “user representatives” and the specialised project owner assistant (see above).

Training the players

It should be remembered that citizenship at work in general and during the IT project implies rights, but also duties. Among these duties, that to inform oneself is essential, but presupposes that one has the skills to understand the information available. These skills can be acquired through experience, but also through training.

As democratic dialogue in IT projects is rarely (or not at all) practised in many organisations, specific training should be provided:

• for non-IT specialists on managing IT projects and their constraints
• for everyone on democratic dialogue methods and themes related to well-being and citizenship at work.

These training courses can be offered to project owner assistants who specialise in well-being and citizenship at work, to key users, to IT project managers, but also to Scrum managers, as well as individuals likely to take on the role of project manager.

APIDOR offers an introduction to IT project management for non-IT specialists (see IT projects: key points).

Some key points for democratic dialogue

We are presenting here just a few summarised points on the procedures that should enable a democratic dialogue to take place.

The ISIDOR method provides a set of tools, in particular checklists. We refer you to these for consultation (see opposite).

In order for democratic dialogue to develop during the project, it is important that all parties agree on the rules for expressing disagreement. This notion of ‘conflictual consensus’ was promoted by the French philosopher Paul Ricoeur³.

Here are some important points to consider:

• Project bodies: completeness of the list of committees, effectiveness of their role, representativeness of their members (as assessed by future users of the application and those affected by it), procedures for managing dissensus and conflict, etc.
• Quality of information about the project: choice of information transmitted (choice made by whom?), choice of recipients (list defined by whom?), possibilities for feedback/validation and requests for additional information.
• Topics for discussion/agendas for meetings: open nature of the definition of topics and agendas, formalisation and transmission of agendas, etc.
• Conduct of meetings: effective opportunity for all participants to express their views, explicit and debated deliberation and decision-making processes, method of seeking consensus/consent.
• Citizen and non-citizen players in the IT project: distribution of powers to define procedures, decision-making processes, define meeting agendas, effective participation in meetings; powers of players from outside the organisation.

Categories used during the project (users, NFRs, etc.), examples of requirements

Categories, typologies, nomenclatures, classifications, etc. are present at every stage of an IT project.

They can be used to define user types (for expressing requirements or defining rights: see User stories models and Initiation phase), but also the types of non-functional requirements (needs) (see Needs/Requirements and NFR in agile approaches), types of criteria for choosing off-the-shelf software, types of acceptance criteria for a user story, and so on.

No category is natural: categories are always constructed and they always reflect a particular way of seeing things, or even a particular view of the world.

Once constructed, categories are often performative, in the sense that, through the implementation of decisions and tools based on these categories, they will bring them into real existence (even if they did not originally correspond to any proven materiality). But also in the sense that they will make invisible anything that does not belong to the list of these categories.

A democratic dialogue must absolutely question the categories used during the project and check that they do not hinder the effective consideration of needs linked to well-being and citizenship at work.

Beyond this, and because they express particular visions of things, it can be argued that the categories should not be pre-constructed, but on the contrary that their very construction should be the subject of dialogue/debate/negotiation.

There are two typologies which are particularly worth considering during an IT project: those relating to users, and those relating to non-functional requirements (see below).

User categories

User categories generally consider users solely as individuals, which means that workgroups are not taken into account in IT projects. What’s more, these typologies are based on purely functional categories, taking no account of the conditions under which work is actually carried out.

Personae, or fictitious users are an expression of the vision of users that certain project stakeholders may have. Personae can also be performative.

Categories of non-functional requirements (NFRs)

The many typologies of NFRs do not generally include aspects of well-being and citizenship at work. The only category that comes close is that of usability, which is very limited (see NFRs).

These typologies should be supplemented with NFRs on well-being and citizenship at work.

The table below presents some (non-exhaustive) proposals for needs (requirements) in terms of well-being and citizenship at work.

Please note: some of the needs proposed in this table are relatively easy to identify, while others require a certain maturity on the part of the organisation in terms of democratic dialogue around digital technology.

Some of these requirements are NFRs, others are FRs. But the 5 categories proposed (Requirement for explicitness & alternative visions, Autonomy, Decision & steering system, Citizen participation in software development, Time & organisational learning) can constitute a typology of NFRs for needs in well-being and citizenship at work.

Proposed requirements for wellbeing and citizenship at work

Project management system

The project management system must be known to all, and its elements must be clearly explained: project objectives, how their achievement will be measured, indicators used and their “acceptable” value ranges, etc.

Project dashboards, indicators

As mentioned for the categories, no indicator is “natural”; they are all expressions of a way of seeing things, often of a representation of the world.

A democratic dialogue must pay close attention to the indicators chosen, how they are calculated, the choice of their values, etc.: indicators of task completion, response to a need (acceptance criteria), efficiency, quality, costs, meeting deadlines, etc.
In a context of genuine democratic dialogue, these indicators must be co-constructed and/or, at a minimum, be subject to consent.

Attention must be paid to the balance in the dashboards: quantitative vs. qualitative indicators, financial vs. non-financial indicators, a posteriori indicators (measuring past performance) vs. a priori indicators (measuring the determinants of future performance).

The dashboards containing the project management indicators must be accessible to all project stakeholders, particularly those whose work is evaluated by these dashboards (project team). The definition and calculation method for all components of these dashboards must be easily accessible to project stakeholders.

Those most directly involved in the democratic dialogue should be able to propose the addition of indicators they deem useful during the course of the project.

Second monitoring loop: it is also desirable that a review of the dashboards be carried out during or at least at the end of the project to assess the relevance of the objectives and indicators themselves.

The democratic dialogue logbook: a monitoring tool

A document tracking everything related to democratic dialogue and the issues it addresses can be very useful.

This “democratic dialogue logbook” should enable the monitoring of the consideration (but also the evolution) of the needs arising from democratic dialogue, the difficulties encountered, the trade-offs made, etc.

It should be initiated during the Initiation phase with the needs expressed in terms of well-being and citizenship at work, and kept up to date throughout the project.

It makes it possible to verify that the application does indeed include the needs related to these themes, and serves as a record of the democratic dialogue process within the project. In this latter capacity, it can be a support for organisational learning about democratic dialogue in digital projects.

Project time, organisational learning

Time is an essential resource for IT projects, but also for democratic dialogue.
The total time allocated to the project, as well as the project schedule, must therefore be weighed against the constraints inherent in democratic dialogue.

Gathering and understanding needs related to well-being and citizenship at work takes time (interviews, etc.). As such, the schedule must allow sufficient time for the first two phases of the project, especially the first (Initiation phase).

Democratic dialogue in projects carried out using a full agile approach may be made more difficult by the absence of these first two phases in their entirety and will require special attention (see Iterative and incremental model and Sprint 0).

As already mentioned, in many organisations, democratic dialogue in IT projects is rarely or never practised. There is therefore a lack of knowledge and experience on this subject, both among project management team and among “traditional” social dialogue actors (elected staff representatives, etc.).

Managing feedback and capitalising on knowledge are important challenges for organisational learning in terms of democratic dialogue in IT projects. As mentioned above, the “democratic dialogue logbook” can be a useful tool for this learning process.

To promote this organisational learning, a certain degree of stability among the actors is desirable. The existence of specialised Porject Owner assistants, as well as the training of certain IT project managers and certain employee representatives, can help to build a group of people who are experienced in issues of well-being and citizenship at work and who are likely to gain skills as they support IT projects.