Livre blanc « Y a-t-il un pilote dans l’avion ? »

Important :  Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

« S’il y a un pilote à bord, peut-il se manifester en actionnant son bouton d’appel ? ». Voilà une phrase qu’aucun passager ne souhaite entendre au cours d’un vol. J’ai relu récemment un article relatant un incident de ce type survenu en décembre 2013. Suite au malaise du pilote d’un vol au départ de Des Moines (États-Unis), le co-pilote avait demandé aux éventuels pilotes à bord de se manifester. Pilote de bombardier B1 dans l’US Air Force, le capitaine Mark Gongol, s’est présenté et a permis à l’avion, aux passagers et à l’équipage d’atterrir sans encombre.

Cette belle histoire m’est revenue en mémoire dernièrement à une occasion bien différente. Un client potentiel nous a contacté pour nous demander s’il pouvait « piloter » notre logiciel de gestion des feuilles de temps pour les projets d’entreprise. Je marque toujours une pause lorsque je reçois ce type d’appel. Lorsqu’on parle de « pilote » dans un avion, nous sommes tous d’accord sur le sens à donner à ce terme. En revanche, je ne suis pas certain que ce soit le cas lorsqu’on parle d’une personne chargée d’évaluer les options relatives aux logiciels.

Dans le domaine des logiciels, le terme « pilote » est souvent associé à d’autres méthodes d’évaluation complexes, telles que les « preuves de concept ». Je vous propose d’examiner ensemble la signification de ces termes et de voir comment les utiliser au mieux dans le cadre du processus d’évaluation de votre entreprise.

Preuve de concept

Ce terme est utilisé depuis de nombreuses années et est très répandu dans le domaine du génie électrique. À l’époque, le montage expérimental d’un circuit permettait de déterminer si sa création était possible, le but n’étant pas de commencer à le créer dans une optique de production. Dans le cadre de l’établissement d’une preuve de concept, il est possible que vous passiez davantage de temps à effectuer des tests en laboratoire qu’à créer le circuit destiné à la production. La seule chose que vous pouvez alors endommager est la carte de circuit imprimé sur laquelle vous travaillez. Cette méthode destinée à prouver qu’un circuit électrique pouvait fournir le résultat prévu était peu onéreuse et présentait peu de risques.

Dans le domaine des logiciels, une preuve de concept est destinée à prouver quelque chose. Lorsque des clients potentiels me contactent pour que je les aide à établir une preuve de concept pour un logiciel de gestion de projets ou de feuilles de temps, j’ai toujours la même réponse : « Quels concepts cherchez-vous à prouver ? ».

Celle-ci est généralement accueillie par un silence gêné.

Si vous comptez établir une preuve de concept et que vous ne parvenez pas à cerner ce que vous voulez prouver, comment saurez-vous s’il s’agit d’une réussite ou d’un échec ? C’est impossible bien évidemment.

Vous vous demandez sûrement « Pourquoi établir une preuve de concept alors ? ». Le plus souvent, le demandeur ne dispose pas de l’adhésion des décideurs pour implémenter le logiciel objet de la recherche, et espère qu’une simple démonstration permettra de convaincre les décideurs d’accepter le déploiement. Dans ce cas, la « preuve » est destinée aux décideurs et le « concept » est l’idée globale associée au logiciel d’entreprise.

S’il était aisé de convaincre la direction de l’intérêt d’un logiciel d’entreprise pour la gestion des projets et des feuilles de temps, un bien plus grand nombre d’entre eux serait déployé.

Le problème de cette méthode est qu’il y a peu de chances que le travail que vous allez fournir pour déployer cette instance de preuve de concept rencontre le même soutien que celui que recevrait le déploiement en production d’un système d’entreprise. Lorsqu’une organisation déploie un système d’entreprise (par exemple, un système de gestion des projets ou des feuilles de temps), la réussite de l’opération dépend de plusieurs facteurs. Tout d’abord, la direction et le personnel doivent s’exprimer sur tous les aspects de l’organisation impliqués dans le déploiement. Il faut ensuite prévoir du temps pour la configuration, obtenir l’assistance des services techniques pour faire le lien avec les autres systèmes d’entreprise, obtenir le soutien de la direction, prévoir du temps pour la formation et obtenir un financement.

Si vous n’avez aucun de ces éléments, quel système fera l’objet de votre preuve de concept ? Au mieux, il s’agira d’une pâle copie du résultat que vous espérez atteindre. Dans cette nouvelle ère du cloud, vous pouvez probablement accéder à un système entièrement hébergé qui vous évite de devoir acheter des serveurs et logiciels et vous permet d’avoir un système dont l’installation ne représente qu’une fraction du travail nécessaire à un déploiement même basique de votre système preuve de concept.

Il est facile de comprendre pourquoi une organisation hésitera à octroyer des ressources et des fonds conséquents à l’implémentation d’un élément pouvant potentiellement affecter l’ensemble de l’organisation. Cet exercice est hautement risqué. Nous avons tendance à parler uniquement des avantages que présentent les logiciels de gestion de projet d’entreprise, mais il est facile d’imaginer que l’échec du même projet peut avoir des répercussions tout aussi négatives. L’atténuation des risques constitue ainsi un aspect essentiel. Mais si le véritable défi est de convaincre la direction des avantages du système, il existe certainement de meilleures façons de procéder. Chez HMS Software, nous mettons notamment l’accent sur les techniques suivantes :

  1. Parler avec un client existant.

    Nous avons la chance d’offrir entière satisfaction à certains de nos clients. Si un nouveau client potentiel cherche à savoir précisément dans quoi il s’embarque, nous mettons en relation son organisation avec un client existant. Souvent, le client existant propose généreusement d’organiser une rencontre en personne. Les deux organisations peuvent aussi parler au téléphone. En pareil cas, nous choisissons délibérément de ne pas faire partie de l’échange. Nous encourageons simplement le client existant à parler des points positifs et des défis rencontrés.

  2. Effectuer une démonstration.

    Si vous avez véritablement un concept nécessitant une démonstration, nous pouvons vous aider. Il peut être légitime que des aspects de certaines implémentations doivent d’abord faire l’objet d’une démonstration. Il est possible que le déploiement inclura de grands volumes de certains types de données. Par exemple, il nous a été demandé une fois de montrer le fonctionnement de notre solution avec une charge de projet particulièrement volumineuse. Il nous a aussi été demandé de montrer le fonctionnement d’un logiciel avec certains navigateurs ou certaines bases de données, ou d’établir un lien avec des versions spécifiques de certains systèmes externes. S’il s’agit du type de concept qui bloque l’évaluation, les spécialistes du sujet sont tout indiqués pour relever le défi.

  3. Suivre une formation.

    Si le client potentiel doit impérativement effectuer une démonstration du système avec les données utilisées par son personnel, nous pouvons aider à charger les données dans un système hébergé, effectuer quelques opérations basiques de configuration du système conformément aux souhaits du client et former les personnes concernées. À choisir, nous préférons intégrer l’entreprise pour participer à la démonstration elle-même. Si ce n’est pas possible, nous demandons à examiner le script ou la démonstration que les intervenants utiliseront et demandons à apporter quelques ajustements ou à former les personnes à la présentation.

Où trouver un pilote quand vous en avez besoin ?

Où en êtes-vous avec le projet pilote ? Vous avez progressé, non ? Possiblement. S’il vous a été demandé de déployer un système pilote de gestion des feuilles de temps ou des projets, vous devez commencer par identifier les objectifs. S’ils ont trait à la seule preuve de concept, vous n’avez pas mis sur pied un projet pilote.

Un projet pilote est un déploiement réel en production et en direct. Il implique généralement un sous-ensemble de la base d’utilisateurs considérée pour l’évaluation du système. L’élaboration d’un programme pilote risque donc de prendre du temps. Même si les besoins de la base d’utilisateurs cible sont considérés dès le départ, le programme pilote a pour objectif de mettre en place une véritable implémentation pour les utilisateurs du pilote. Ceux-ci vont véritablement gérer leurs projets ou compléter leurs feuilles de temps avec le nouveau système.

Les défis qu’un déploiement en production complet impliquent sont également rencontrés par l’implémentation pilote, exception faite du volume ou de la complexité des données. Ceux généralement rencontrés par les projets pilotes que j’ai pu observer sont le manque d’adhésion, l’insuffisance des fonds, du temps et des ressources et, le pire, le manque d’objectifs clairs pour déterminer si le projet pilote a réussi ou non.

Cela ne veut pas dire qu’un projet pilote est médiocre. La mise en place d’un pilote peut être extrêmement délicate. Elle permet de minimiser le risque d’affecter l’ensemble de l’organisation avec un déploiement incomplet ou mal configuré. La réussite d’un projet pilote implique beaucoup de réflexion.

Il y a peu, nous avons commencé à travailler sur un déploiement d’envergure pour une administration. L’exercice a ceci de gratifiant que l’organisation avait déjà pris le temps d’effectuer l’évaluation. Elle a fini par choisi son système d’entreprise. Par chance, il s’agit du nôtre. Nous avons collaboré avec l’équipe en charge de l’évaluation l’année dernière pour nous assurer que toutes leurs questions techniques avaient trouvé réponse. À présent, leurs préoccupations tournent autour de l’impact sur le travail quotidien des membres de cette organisation.

Ils nous ont proposé de travailler pendant 6 mois avec un groupe qui, s’il est relativement important, ne représente que 10 % de l’effectif du groupe. Le budget est adapté, le pilote a reçu le soutien de l’équipe dirigeante et le délai prévu est suffisant pour nous permettre de participer à toutes les opérations que nous assurons normalement dans le cadre d’un déploiement de ce type. Le groupe qui devra travailler dans cet environnement de suivi des projets et des feuilles de temps l’utilisera en production dans un avenir proche. Il ne s’agit donc pas simplement d’un test. L’opération s’apparente plutôt à la première phase du déploiement. Avec tous ces facteurs en place, nous pouvons normalement nous attendre à une issue positive plus tard dans l’année.

En résumé

Les projets de type pilote et preuve de concept font partie du cycle de vie des logiciels d’entreprise. Si vous prévoyez d’en développer un, vous pouvez contribuer à son succès en mettant en avant certains facteurs essentiels auprès des personnes concernées :

  1. Assurez-vous en premier lieu d’avoir clairement défini vos objectifs.

  2. Vérifiez ensuite que la direction comprend vos besoins et vous apportera son soutien en termes de fonds, de ressources et de temps pour vous permettre d’atteindre ces objectifs.

  3. Enfin, veillez à planifier le projet et à le gérer comme n’importe quel autre projet de votre portefeuille.

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) pour Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada, PMNetwork et Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le blog EPM Guidance (http://www.epmguidance.com/?page_id=39).

Remarque : Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×