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 NRFs for needs in well-being and citizenship at work.

Proposed requirements for wellbeing and citizenship at work

Système de pilotage du projet

Le système de pilotage du projet doit être connu de tous, ses éléments explicités : objectifs du projet, mode de mesure de leur atteinte, indicateurs retenus et leurs plages de valeurs « acceptable », etc.

Tableaux de bord du projet, indicateurs

Comme on l’a évoqué pour les catégories, aucun indicateur n’est « naturel », tous sont l’expression d’une manière de voir, parfois d’une représentation du monde.

Un dialogue démocratique doit être attentif aux indicateurs choisis, à leur mode de calcul, au choix de leur valeurs… : indicateurs de fin de tâche, de réponse à un besoin (critères d’acceptation) d’efficacité, de qualité, de coûts, de tenue des délais, etc.
Dans un contexte de véritable dialogue démocratique, ces indicateurs doivent être coconstruits et/ou a minima faire l’objet d’un consentement.

Une attention devra être portée aux équilibres dans les tableaux de bord : indicateurs quantitatifs vs qualitatifs, indicateurs financiers vs non financiers, indicateurs a posteriori (mesurant la performance passée) vs a priori (mesurant les déterminants de la performance future).

Les tableaux de bord rassemblant les indicateurs de pilotage du projet doivent être accessibles à tous les acteurs du projet, et notamment ceux dont le travail est évalué par ces tableaux de bord (équipe projet). La définition et le mode de calcul de tous les composants de ces tableaux de bord doit être aisément accessible aux acteurs du projet.

Les personnes plus directement impliquées dans le dialogue démocratique devront pouvoir, en cours de projet, proposer l’ajout d’indicateurs leur semblant utiles.

Deuxième boucle de suivi : il est également souhaitable qu’une revue des tableaux de bord soit effectuée en cours ou au moins en fin de projet pour évaluer la pertinence des objectifs et des indicateurs eux-mêmes.

Le carnet du dialogue démocratique : un outil de suivi

Un document de suivi de tout ce qui concerne le dialogue démocratique et les thématiques qu’il porte peut être très utile.

Ce « carnet de dialogue démocratique » (backlog de dialogue démocratique) doit permettre le suivi de la prise en compte (mais aussi de l’évolution) des besoins issus du dialogue démocratique, les difficultés rencontrées, les arbitrages faits, etc.

Il doit être initialisé en phase de Cadrage avec les besoins exprimés en matière de bien-être et de citoyenneté au travail, et tenu à jour pendant tout le projet.

Il permet de vérifier que l’application inclut bien les besoins liés à ces thématiques, et sert de mémoire au déroulement du dialogue démocratique dans le projet. À ce dernier titre, il peut être un support à l’apprentissage organisationnel du dialogue démocratique dans les projets numériques.

Le temps du projet, l’apprentissage organisationnel

Le temps est une ressource essentielle pour le projet informatique, mais aussi pour le dialogue démocratique.

Le temps total octroyé au projet, mais aussi le planning du projet, devront ainsi être confrontés aux contraintes propres à l’exercice du dialogue démocratique.

Le recueil et la compréhension des besoins liés au bien-être et à la citoyenneté au travail demandent du temps (entretiens…). À ce titre, le planning doit prévoir un temps suffisant pour les deux premières phases du projet, et tout particulièrement la première (Cadrage).

Le dialogue démocratique dans les projets menés selon un approche agile « complète » (qui inclut toutes les phases) pourra être rendu plus difficile par l’absence de ces premières phases dans toute leur extension et demandera une attention particulière (voir Modèle itératif et incrémental et Sprint 0).

Comme cela a déjà été évoqué, dans de nombreuses organisations, le dialogue démocratique dans les projets informatiques n’est que peu ou pas pratiqué. Il y a donc un déficit de connaissances et d’expérience sur ce sujet, aussi bien chez les acteurs de la MOE que chez les acteurs « traditionnels » du dialogue social (représentants du personnel élus…).

La gestion des retours d’expérience, la capitalisation des connaissances sont des enjeux importants pour un apprentissage de l’organisation en matière de dialogue démocratique dans les projets informatiques. Comme on l’a dit, le « carnet de dialogue démocratique » peut être un support à cet apprentissage.

Pour favoriser cet apprentissage organisationnel, une certaine stabilité des acteurs est souhaitable. L’existence d’assistants MOA spécialisés, mais aussi la formation de certains chefs de projet informatiques ainsi que de certains représentants du personnel peut permettre de constituer un groupe de personnes expérimentées dans les questions de bien-être et de citoyenneté au travail et susceptibles de gagner en compétences au fur et à mesure des projets informatiques qu’elles accompagneront.