Planifier un projet innovant

Récemment, nous discutions avec Cédric Carvalho, un ami de l’université, des problèmes rencontrés lorsque l’on travaille sur un domaine nouveau. Un de ces problèmes est qu’il est difficile de prédire finement la date de sortie d’un projet innovant à partir d’un cahier des charges pour de multiples raisons. Le cahier des charges est amené à évoluer au fur et à mesure du développement du projet (méthode agile). De plus, l’estimation du temps de réalisation d’une tâche de programmation est souvent trop optimiste, et ne prend pas en compte les difficultés et opportunités de la réalité. Face à une telle difficulté, pourquoi s’entêter ? Parce qu’une prédiction fine de la date de sortie du projet permet à l’équipe marketing de créer une campagne adaptée, et à l’équipe administrative d’anticiper la trésorerie de l’entreprise.

Cédric m’a conseillé de lire, et j’ai donc lu, Work Rules! (livre en anglais) écrit par Laszlo Bock, le Senior Vice Président of People Operation (Expert vice président de l’équipe management ?) de Google.

De cette discussion dans un petit café a émergé la problématique suivante:

Comment planifier finement la date de sortie d’un projet innovant tout en laissant une marge de manœuvre suffisante à mes collègues pour qu’ils puissent s’adapter aux difficultés et saisir les opportunités ?

Afin de répondre à cette problématique, dans un premier temps (« La culture mange la stratégie au petit déj »), je commenterai une portion de Work Rules!. Ensuite je proposerai deux réponses possibles (Trop de planification tue la planification et Davantage d’informations et d’autonomie) à la problématique.

« La culture mange la stratégie au petit déjeuner »

Work Rules! est très structuré. Il parle des nombreuses manières de façonner une entreprise qui permettent à chaque employé d’avoir envie de travailler dans cette entreprise (recrutement), d’avoir les moyens de bien y travailler (management), et d’avoir envie de rester dans cette entreprise (culture). Ici la culture représente un ensemble de valeurs et de signes partagés par la majorité des intervenants. («Culture d’entreprise, par Christophe Durand, Jean-François Fili, Audrey Hénault, 2000»)

Le chapitre qui m’a semblé le plus en lien à ma problématique est le chapitre 2 « Culture eats strategy for Breakfast » (« La culture mange la stratégie au petit déjeuner »). Ce chapitre parle de la confiance et des nouvelles manières de manager par l’information et les valeurs. Spécifiquement lié à la planification et à la marge de manœuvre, le message de l’auteur est clair :

« Si tu penses que les gens sont bons, tu ne devrais pas avoir peur de partager les informations avec eux. Donnes de la liberté aux gens et ils ne cesseront de t’étonner. »

Il faut avoir confiance en nos collègues et ne pas micro-manager. Les conseils qu’il prodigue se situent au niveau de l’entreprise et au niveau de la personne.

Schéma représentant la relation des différents concepts abordés dans « La culture mange la stratégie au petit dèj » Une culture de la transparence et de la confiance dont tout découle. Matthieu Talbot(2016) serendipiteur.fr

Au niveau global, les éléments principaux permettant à une entreprise de surmonter les obstacles inhérents à l’innovation sont:

  • d’avoir une mission qui importe à chaque employé. Cette mission guidera la culture de l’entreprise, culture qui servira de compas moral aux employés pour naviguer parmi les différentes options de réalisation de l’objectif. Exemple de Google : Notre mission est « d’organiser l’information du monde et la rendre universellement accessible et utile »
  • partager les informations par défaut. Ainsi, tout le monde sait ce qui se passe. Autant de franchise permet, par exemple, d’optimiser le travail redondant. Dans le livre, l’auteur parle également une situation où il envoie un mail à une collègue Anne disant du mal de son collègue Bernard. Sa collègue Anne a juste mis Bernard en copie pour forcer les personnes concernées par ce conflit humain à s’y confronter directement. Dans certaines cultures, cela pourrait s’assimiler à de la délation. Mais ici, cela permet plutôt d’arriver plus rapidement à une solution.
  • être ouvert à la discussion et canaliser toute frustration des employés en efforts pour renforcer la culture. L’auteur note que le fait que des employés craignent de perdre la culture est un bon signe car elles seront vigilantes aux menaces qui peuvent altérer cette dernière.
  • célébrer systématiquement l’échec des employés qui ont pris des initiatives pour ne pas stigmatiser les personnes qui ont osé viser la lune sans réussir au premier essai.

Au niveau personnel, la recette d’un employé qui parvient à ses objectifs en les dépassant est:

  • un objectif précis, qui se connecte clairement à la mission de l’entreprise
  • un fort sentiment d’appartenance à la culture d’entreprise.
  • une connaissance du contexte de l’entreprise: ce qui s’y passe, et surtout comment et pourquoi.
  • des réponses franches aux interrogations à propos des informations qui lui manquent.
  • de la marge de manœuvre pour pouvoir prendre des initiatives sur des idées nouvelles non anticipables par le management top-down.

Trop de planification tue la planification

Ma problématique était Comment planifier finement la date de sortie d’un projet innovant tout en laissant une marge de manœuvre suffisante à mes collègues pour qu’ils puissent s’adapter aux difficultés et saisir les opportunités.

Dans une entreprise dont l’objectif est innovant, la vie réelle se charge de placer un nombre important d’embuches qui rendent toute planification difficile, voir impossible. Faut-il pour autant abandonner l’idée même de planification ? Que nenni ! Il serait déraisonnable de se priver d’indicateurs de progression estimée. La déviation entre la progression réelle et la progression estimée est un signal fort qui permettrai de déclencher le tir correctif qui sauvera le projet.

Mais à vouloir planifier trop finement, on se retrouve dans le tort inverse: micro-manager de manière directive pour s’assurer que les délais sont bien tenus. Or ce mode de management réduit fortement la marge de manœuvre nécessaire aux prises d’initiatives audacieuses.

Davantage d’informations et d’autonomie

D’après moi, c’est l’idée même de planification qu’il faudrait revoir. Trop de planification tue la planification, et essayer d’anticiper finement les durées de réalisation est contre-productif. Il est donc préférable de mieux se concentrer sur le management des employés: leur donner un champ d’action élargi, des objectifs clairs, et toutes les informations leur permettant de réaliser leurs objectifs de la manière qui semble, selon eux, la plus appropriée. Comment pouvons-nous planifier dans ces conditions ? Entre autre, en gonflant les estimations de temps de réalisation afin de se laisser le temps de célébrer les échecs et d’anticiper les imprévus (cf « La culture mange la stratégie au petit déj »).

En prenant du recul, ce type de management favorisant l’autonomie permet d’améliorer la vie de l’entreprise et celles de ses employés. C’est une pratique à long terme qui se traduit par une meilleure motivation et un sens de l’initiative accrue des employés, ainsi que des innovations plus fréquentes.


Image de couverture : «Célébrer l’échec flowchart». Matthieu Talbot(2016) serendipiteur.fr

PS: En rédigeant cet article, je me suis rappelé du site re:work (lien en anglais) dont les conseils sont proches de ce que le livre suggère. En réalité, re:work tout comme Work Rules! est un produit Google, bien que le branding y soit discret.

Laisser un commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax