Actualité

Le business analyst (BA) ou analyste d’affaires est une personne qui aide les organisations à améliorer leurs processus, services et produits grâce à l’analyse des données, de la documentation et à l’évaluation du business model ou de son intégration avec la technologie (il aide à combler le fossé entre la partie informatique et Business). Le business analyst a pour rôle :

• L’identification des besoins de changement de l’entreprise et l’évaluation de leur impact sur l'entreprise,
• L'analyse, la documentation et la communication des exigences avec les parties prenantes concernées.

 

Le rôle du business analyst

L’activité principale des analystes d’affaires consiste à aider les entreprises à mettre en œuvre des solutions technologiques de manière rentable. Le professionnel doit déterminer les exigences d’un projet ou programme et les communiquer clairement aux parties prenantes.

Le business analyst est le professionnel responsable de la recherche de solutions techniques aux problèmes de l’entreprise. En outre, il définit, analyse et documente les besoins, en étudiant l'entreprise dans sa globalité et les besoins en informations de l’organisation.

 

Les responsabilités du business analyst 

Les responsabilités du business analyst peuvent varier d’une entreprise à l’autre. Certaines responsabilités peuvent être limitées à des projets liés aux technologies de l'information, alors que d'autres organisations peuvent impliquer le business analyst dans des domaines tels que les ventes, la finance, le marketing ou les opérations.

Quoi qu’il en soit, le business analyst doit conserver une vision holistique des systèmes de l’entreprise en se concentrant sur 4 domaines clés:

• L’organisation,
• Les personnes,
• Les processus,
• La technologie.

 

Les responsabilités communes des BA sont 

La création d'une analyse détaillée de l’entreprise, décrivant les problèmes, les opportunités et les solutions pour l’entreprise. L’analyse de la structure d'entreprise, son utilisation de la technologie et ses objectifs :

• La formulation de pistes d’amélioration,
• L’analyse stratégique,
• La cartographie des processus et des flux de valeur,
• La cartographie des aptitudes et des compétences,
• L’aide à la conception, la documentation et le maintien des processus du système,
• La supervision et la mise en œuvre de nouvelles technologies et systèmes,
• La communication des informations clés et des résultats à l'équipe produit,
• La définition et communication des exigences de l'entreprise aux parties prenantes.

 

Les compétences du business analyst

Selon le guide BABOK®, les compétences principales du business analyst peuvent être identifiées suivant 6 catégories de compétences :

• La pensée analytique et la résolution des problèmes,
• Les caractéristiques comportementales,
• Les connaissances Business,
• Les compétences en communication,
• Les compétences relationnelles,
• Les applications et logiciels.

 

1. Les compétences analytiques et la capacité à résoudre les problèmes sont les compétences essentielles du métier de Business Analyst et comprennent:

• La pensée créatrice,
• La prise de décision,
• La résolution de problème,
• La pensée critique.

 

2. Les caractéristiques comportementales sont essentielles pour gagner la confiance des parties prenantes, puisque le BA aura accès à des informations, des systèmes et d’autres actifs de grande valeur et sera impliqué dans des projets critiques. Ces compétences comprennent:

• Les compétences interpersonnelles et consultatives,
• La gestion du temps et les compétences organisationnelles.

 

3. Les connaissances Business donnent au BA un avantage supplémentaire et comprennent :

• Les principes et pratiques Business,
• Les connaissances de l'industrie,
• Les connaissances organisationnelles.

 

4. Le BA doit s’assurer qu’il communique clairement ses principales idées et ses observations/conclusions. C’est pourquoi les compétences en communication sont des compétences clés comme par exemple :

• Les compétences en communication orale et écrite,
• La communication visuelle,
• L’écoute active.

 

5. Le Business Analyst facilite les interactions entre les parties prenantes afin de les aider à exprimer leurs besoins et à résoudre les désaccords concernant la priorité et la nature des exigences. Ces compétences relationnelles comprennent :

• La conciliation, la négociation ou la médiation,
• Les compétences en leadership et en management,
• Le travail en équipe.

 

6. Le Business Analyst doit avoir une connaissance des applications et des logiciels qui sont susceptibles de l’aider dans son activité quotidienne, des plus populaires aux plus spécialisés, tels que les systèmes de gestion de documents, les systèmes de gestion de contenu, etc. qui sont parfois construits spécialement pour l’organisation pour laquelle il travaille.

Quelle est votre fonction actuelle ? Quelles sont vos missions ?

Je suis responsable du domaine gouvernance et gestion de projet de façon transverse pour les différents bureaux, au sein d’ITECO. Je définie et promeus l’offre et j’apporte le support méthodologique, le «knowledge management» aux différents bureaux de gestion de projets.

A côté de ça, j’ai également une activité de consultant auprès d’un certain nombre de client, en relation avec le périmètre gouvernance et gestion de projet.

 

Comment êtes-vous arrivé à effectuer une carrière en gouvernance et gestion de projet ?

J’ai suivi la voie classique à l’époque, c’est-à-dire que j’ai commencé ma carrière à Bruxelles en tant qu’analyste-programmeur en systèmes bancaires, puis à Paris pour contribuer au logiciel d’assurance. Après cela, j’ai eu l’opportunité de rejoindre un fournisseur de logiciels développant des solutions pour les groupes financiers. Avant de rejoindre Itecor, j’ai travaillé pendant plusieurs années en tant que consultant puis chef de projet chez Cap Gemini Suisse.

En 15 ans d’expérience en gestion de projet, j’ai eu l’opportunité d’intervenir sur d’autres sujets en relation avec la gouvernance en générale, le service management, la gestion de portefeuille, l’arbitrage des investissements et j’ai également réalisé beaucoup d’audit.

Mon expérience – et mes cheveux gris – m’ont permis de m’orienter vers ce type de prestation en faisant moins de gestion de projet. Je conseille désormais un certain nombre de clients en matière de GRC, de gestion de portefeuille, de gestion de service. Ses prestations sont pour moi, un excellent moyen de partager la connaissance et l’expérience acquises, en complément d’une gestion de projet pure et dure. J’interviens toujours au niveau de la gestion de projet mais sur des aspects méthodologiques, en proposant des prestations de conseil et des formations.

 

Quel est le plus gros changement auquel vous avez dû faire face lors de l’implémentation des Bonnes Pratiques dans vos portefeuilles projets ?

Basé sur mes expériences, j’ai constaté un réel changement dans l’attitude des directions ces 5 dernières années. Au-delà de l’aspect technique de la gestion de projet, il y a une plus grande sensibilité des directions à la notion de portefeuille de projet, au besoin d’avoir de la visibilité sur les projets, sur leur investissements et également de pouvoir exercer un arbitrage sur ces investissement.

Je trouve ce changement très intéressant car il place enfin la gestion de projet au bon niveau, c’est-à-dire au niveau du pilotage stratégique et de l’arbitrage, là où il aurait dû être depuis toujours.  

Quel est l’impact ce changement sur le quotidien des chefs de projet, si il y en a un ?

Il y a en effet des répercussions sur la gestion de projet. Je ne parlerais pas de complications mais cela implique effectivement d’avantage d’exigences. Le fait de mettre en place une gestion de portefeuille, ne fût-ce que pour la remontée d’information et le suivi d’indicateur des projets, nécessite plus de rigueur.

Le chef de projet doit désormais renseigner les différents indicateurs plus régulièrement mais également structurer le projet par phase (si on souhaite une découpe par phase plus ou moins homogène au niveau d’un portefeuille).

L’impact peut être important sur la gestion de projet dans les situations où les chefs de projet géraient de façon peut-être trop laxiste le projet, sans être hyper rigoureux ou pas totalement dans un outil et se retrouvent face à des exigences plus importantes, qu’ils doivent désormais satisfaire.

 

Selon vous, ce changement est-il compatible avec la gestion de projet Agile ?

Malgré ce qu’on peut entendre, je ne pense absolument pas qu’une méthode agile réduise le contrôle. L’Agilité amène bien au contraire, un contrôle ou un suivi beaucoup plus proche de la réalité.

Il peut éventuellement y avoir une problématique de remontée d’information, qui est uniquement technique, entre un cadre méthodologique agile qui a ses propres indicateurs et les indicateurs classiques des méthodes traditionnelles.

On voit d’ailleurs émerger cette notion de projet hybride, dans lequel on voit cohabiter des projets traditionnels (waterfall), des projets purement agiles et des projets mixtes (hybrides). Le mélange est très intéressant car il combine par exemple, les aspects d’infrastructure d’une démarche classique et les aspects de développement une démarche agile.

D’une manière générale, chacun interprète les méthodes agiles comme il le veut, souvent par manque de connaissance. Il y a souvent cette perception d’équipe qui s’auto-organise où l’on s’imagine que les membres de l’équipe font ce qu’ils veulent dans leur coin, sans la moindre autorité ni contrôle.

En réalité c’est plutôt l’inverse, un projet agile demande énormément de rigueur si l’on souhaite le mener à bien, d’où l’importance de s’appuyer sur un cadre de référence ou une méthodologie pour fixer un cadre structuré.  

Avez-vous des leçons tirées de l’expérience ou conseils à partager avec les PMO ?

Une des spécificités de notre marché est qu’il n’est pas rare de rencontrer des chefs de projet dits « de milice ». Ces professionnels sont parfois des gens du métier, des informaticiens, qui n’ont pas nécessairement une formation ou une expérience poussée dans la gestion de projet et à qui on confie des projets.

Le conseil que je me permettrais de donner, par rapport à ce constat de miliciens, à qui l’on demande de conduire des projets en plus de leurs activités opérationnelles, est de laisser le temps à un PMO de commencer petit et de grandir. Il est important de permettre au PMO de se déployer pas à pas, pour ne pas perdre les chefs de projet et les faire monter graduellement en compétences.

Il faut également faire attention de prendre le temps de monter une structure, d’avoir une ambition qui correspond à la réalité du terrain et de ne pas monter un PMO en compétence pour le plaisir du PMO. Le cas échéant, le danger est de se couper de la réalité des chefs de projet en leur imposant des exigences avant tout méthodologique et non pragmatique. Il faut nous, être pragmatique et y aller progressivement, bien embarquer les chefs de projet dans la mise en œuvre d’un PMO ou d’un portefeuille de projet.  

Quelles sont selon vous les étapes majeures pour mettre en place un PMO ?

La première chose à faire, qui rejoint ce qui a été mentionné auparavant, c’est de définir ce qu’on attend de ce bureau de support et les objectifs à atteindre. On sait que les PMO sont à géométrie variable selon les entreprises, ils peuvent avoir des rôles et objectifs qui diffèrent d’un environnement à un autre.

La première chose à faire est donc de définir les objectifs et les bénéfices business qui sont attendus. Encore une fois, il ne faut pas faire de la technique pour faire de la technique ni de la méthodologie pour faire de la méthodologie, mais veiller à ce que la mise en place d’une organisation de ce type réponde aux objectifs métiers et que ces derniers ont été clairement définis et communiqués à l’ensemble des parties prenantes.

Il faut ensuite calibrer son PMO par rapport à ces objectifs définis et validés par la ou les directions, puis progressivement mettre en place le PMO, de façon classique. Cette première étape d’alignement sur les besoins métiers est primordiale selon moi.

Ensuite pour les professionnels qui ne connaissent pas les étapes suivantes, je pourrais leur recommander de suivre une ou plusieurs des formations QRP International, mais je dirais encore une fois, la prochaine étape dépend des attentes du PMO.

Pour moi, en termes d’attente, un PMO doit pouvoir mettre à disposition des chefs de projets auprès des projets, apporter un support méthodologique, effectuer les remontées d’indicateurs mais également de gérer le portefeuille. En fonction des objectifs visés, il faut définir les objectifs et les prestations du PMO à mettre en œuvre.

Je conseille vivement d’instaurer une culture métier de base, si elle n’existe pas. Quand je dis une culture métier de base, j’entends définir ce qu’est un projet, définir si il y a des découpes en phases qui doivent être respectées et qui peuvent varier d’un projet à l’autre et déterminer les indicateurs et les responsabilités du chef de projet par rapport à l’activité du PMO.

Une fois que tout cela est défini, les étapes suivantes consistent à mettre progressivement ces éléments en place et amener petit à petit la rigueur souhaitée auprès des différents projets.

 

Quelles sont pour vous les clés du succès d’une transformation organisationnelle ?

La clé du succès d’une transformation organisationnelle est selon moi la conduite du changement, que l’on retrouve en tant que telle comme méthodologie et mais également associée à la gestion de programme. Je ne parle pas du côté technique mais plus de l’accompagnement des personnes.

 

Quelles sont les compétences et qualités d’un bon PMO ?

Tout dépend des attentes du PMO mais en général :

• l’expertise en gestion de projet, notamment pour apporter du support au chef de projet les relations humaines, qui sont primordiales,
• garder à l’esprit les besoins et objectifs stratégiques (ne pas suivre une démarche purement méthodologique mais s’adapter et être à l’écoute du business).

 

Citez trois notions que vous souhaiteriez apprendre dans un proche avenir pour vous développer en tant que professionnel ?

• Tout d’abord, d’un point de vue personnel, je souhaite en savoir plus sur les aspects compliance et contrôle interne.
• Ensuite, sur le plan projet, je voudrais développer la problématique des données personnelles à prendre en compte dans une démarche projet, c’est-à-dire d’un point de vue de la découpe en activité, de bien positionner cette problématique dans la gestion de projet.
• Enfin, j’aimerais améliorer mes connaissances actuelles sur la sécurité de l’information dans l’optique de la certification ISO 27 000.

 

Alain Geerts

Avec plus de 25 ans d’expérience professionnelle en informatique, dont 15 ans en gestion de portefeuille, de projet et en conseil informatique, Alain est un manager et consultant senior spécialisé dans les domaines de la gouvernance informatique, de la conformité, du contrôle interne et des Bonnes Pratiques.

Suivez Alain sur Linkedin.

Pour ceux qui se penchent pour la première fois sur le monde Agile, les deux rôles Scrum Master et Chef de Projet peuvent sembler similaires, mais en réalité, ils ne le sont pas. Le Scrum Master et le Chef de Projet jouent deux rôles très différents.

Le Chef de Projet est un leader qui gère le projet et son équipe. Sa responsabilité principale est d’atteindre les objectifs du projet.

Le Scrum Master a un rôle de facilitateur, de coach pour l’équipe Scrum. C’est un servant leader qui veille à ce que le cadre de référence Scrum soit compris et utilisé par tous les membres de l’équipe et qui élimine les obstacles suceptibles de nuire au travail de l’équipe de développement. Il est considéré comme coach, facilitateur pour diverses raisons :

1. Contrairement au Chef de Projet, il ne gère pas l'équipe projet, mais veille au respect des valeurs et des principes du cadre de référence Scrum.
2. Le Scrum Master soutient le Product Owner.
3. Il est responsable des processus Scrum, de leur mise en œuvre correcte et de la maximisation de leurs bénéfices.

Si le Chef de Projet guide la planification des activités pour l'exécution du projet, le Scrum Master soutient les autres membres de l'équipe, travaillant en étroite collaboration avec eux, tout en veillant à ce que les principes Agile soient correctement suivis.

Le Scrum Master se distingue du Chef de Projet pusqu’il n'assigne pas de tâches aux membres de l'équipe et ne leur dit pas quoi faire. Il a pour rôle de faciliter le processus en aidant l'équipe à s'autogérer et à s'auto-organiser. Les équipes Scrum se différencient de la structure hiérarchique de la gestion de projet traditionnelle puisqu’elles s’auto-organisent: les membres de l’équipe choisissent comment s’organiser pour mener à bien leur travail et ne reçoivent aucune instruction de l’extérieur.

Les responsabilités du Chef de Projet traditionnel, dans un projet Agile, sont réparties entre:

• Le Product Owner.
• Le Scrum Master.
• L’équipe de développement.

Les activités du Scrum Master changent quotidiennement en fonction des besoins de l’équipe: le Scrum Master doit permettre à l’équipe de mener à bien son travail en la protégeant des risques externes. Il joue un rôle fondamental car il accompagne l’équipe dans son cheminement vers la réussite du projet.

Le Chef de Projet se concentre sur le projet, tandis que le Scrum Master se concentre sur l'équipe et ses membres. Le Chef de Projet doit s'assurer du succès du projet, tandis que le Scrum Master doit s'assurer que l'équipe réussit.

 

Le Chef de Projet dans un contexte agile: relation avec l'équipe Scrum

Il peut arriver que les entreprises passent des méthodes traditionnelles à des méthodes agiles et que le Chef de Projet ait beaucoup de difficultés à passer aux processus agiles, précisément en raison des différences de fonctionnement entre les deux types d’équipes traditionnelles et agiles.

Dans un contexte agile, le Chef de Projet doit déléguer la planification détaillée aux équipes Scrum. La relation entre les Chefs de Projet et les équipes de développement a tendance à être plus informelle: le rôle du Chef de Projet est beaucoup plus centré sur la garantie que les équipes Scrum travaillent dans le bon contexte que sur la vérification du travail spécifique effectué par les équipes.

Le Chef de Projet doit collaborer avec les équipes de développement, les aidant à résoudre les problèmes plutôt que de les gérer. Le Chef de Projet doit toutefois s’assurer que l’équipe de développement a bien compris les objectifs convenus au début de chaque timeboxe et comprend l’importance de respecter les livraisons prévues afin d’atteindre les objectifs.

En conclusion, les rôles de Chef de Projet et de Scrum Master sont différents. Certe ils ne s’excluent pas, mais il ne faut pas pour autant penser que le Chef de Projet peut devenir un Scrum Master. En effet, certains Chefs de Projet ne parviennent pas à assumer le rôle de Scrum Master précisément parce qu'ils essaient d'appliquer le style "management et contrôle" dans l'équipe Scrum.

Un bon Scrum Master est un professionnel passionné d’Agile qui sait mettre ses connaissances à disposition des autres, à travers le «servant leadership», peu importe que son background soit plus technique ou issu de la gestion.

 

Sources:

• Schwaber and Sutherland, The Scrum Guide;
• DSDM Agile Project Management Handbook v2;
• Agile Project Management and Scrum v2, DSDM Consortium.

Lors d’une première Interview avec Bernard Gauchier, consultant expert sur les activités de tests et de qualification, impliqué dans la mise en place de la démarche DevOps au sein de grands groupes français, nous mettions en avant les problématiques du mouvement DevOps. Dans ce second article, nous revenons ensemble sur les différentes étapes de l’implementation du mouvement DevOps, les techniques, les conseils et les leçons tirées de l’expérience.

 

Bernard, pouvez-vous nous décrire les différentes étapes de l'implémentation DevOps au sein des entreprises dans lesquelles vous avez travaillé ?

1. Réaliser un audit, comprendre l’existant, et l’organisation actuelle Il est nécessaire de démarrer par une étude des flux d’opérations depuis la conception d’un produit/projet jusqu’à son utilisation/exploitation quotidienne. Cette étape menée par exemple avec l’approche VSM va reconstituer la chaine de valeur, identifier notamment les points de décisions, les contraintes, les temps morts, les pertes d’énergie, et cibler le type d’outillage et d’organisation à viser.
2. Définir des objectifs et traiter les contraintes L’étape suivante, la plus critique, est celle qui définit et apporte les solutions orientées DevOps: Shift Left, Continuous Integration, Delivery et Deployment. Elle va favoriser les expérimentations (POC, Pilote) pour démontrer l’efficacité de ces solutions et alimenter l’adhésion au changement. Il peut y avoir beaucoup d’itérations sur cette étape et il importe de se fixer des objectifs réalistes dans des périodes limitées (six mois à un an) pour démontrer et acter le changement dans un esprit d’Agilité.
3. Amélioration continue La dernière étape consiste à ajuster les solutions et le dispositif DevOps mis en œuvre. A l’aide de tableaux de bord sur les différents axes de gains (productivité, couverture des tests, délai de mise à disposition, taux d’incidents…) on va vérifier la valeur ajoutée fournie à l’entreprise et s’inscrire dans une boucle d’amélioration.

 

Parmi les diverses techniques proposées par DevOps, lesquelles préférez –vous ?

• Value Stream Mapping
• Théorie des Contraintes
• Kanban

 

Avez-vous des leçons tirées de l'expérience ou conseils à partager avec la communauté DevOps ?

Un changement aussi important que celui apporté par DevOps se prépare en impliquant les équipes Développement et Opérations dès le départ. J’ai connu des situations ou l’une des deux organisations conçoit seule l’implantation du DevOps avant de tenter de convaincre un peu tardivement l’autre entité de l’accompagner.

Je conseille de s’appuyer sur un sponsor de la direction générale et de mettre en place très rapidement des groupes de travail mixte pour rapprocher les équipes et éviter le fonctionnement en « silo ». Il est nécessaire de communiquer régulièrement et largement sur les acquis déjà obtenus (QuickWin en particulier).

De plus, ce type de changement dans la gestion du SI peut représenter un investissement initial non négligeable. L’offre en terme d’outillage étant riche et se renouvelant constamment, il faut garder une certaine capacité à changer ou à adapter les solutions choisies. Encore une fois la direction joue un rôle très important dans la communication et des meetings, des séminaires ou des ateliers sont les bienvenus pour maintenir une communication claire et effective.

 

Bernard Gauchier

Consultant expert sur les activités de tests et de qualification, Bernard est également formateur sur les référentiels ISTQB et TMMI. Il intervient sur des programmes de transformation DevOps en mettant en place les procédés et outils de Continuous Testing et en étant impliqué dans la coordination des différents chantiers de transformation et d’accompagnement au changement. Il a récemment complété cette expérience terrain par la certification DevOps Foundation et est en voie de devenir Formateur accrédité.

Suivez Bernard sur Linkedin ou consultez son site internet

Le Service Manager est garant de la bonne fourniture de son service et en charge de sa perpétuelle amélioration pendant toute la durée du contrat et suivant les termes de celui-ci.  

Service Manager, définition

Un responsable de service est généralement responsable de la définition du service, de la gestion des SLA (Service Level Agreement) et de la garantie que les services répondent aux besoins de l'entreprise.

Il / Elle gère les membres de l'équipe du service, mesure et analyse le travail effectué, propose des améliorations aux processus, y compris une interaction avec le service client (plaintes et demandes).

 

Le rôle du Service Manager

La principale responsabilité du responsable de service est d’interagir avec l’équipe commerciale, de comprendre les contrats de SLA et de superviser l’équipe de service chargée du support et de la maintenance des infrastructures.

C’est le professionnel responsable de la création de valeur pour les clients, mais sous forme de services.

 

Les responsabilités du Service Manager

Les responsabilités communes du Service Manager sont :

• Superviser et guider toutes les activités de l'équipe de service.
• Coordonner les créations de SLA (via l'interaction avec l'équipe commerciale).
• S'assurer que l'équipe respecte les Bonnes Pratiques et maintiennent les SLA.
• Surveiller les problèmes du service et les plaintes des clients.
• Élaborer des plans de gestion des problèmes et d’amélioration des services.
• Veiller à ce que les clients, le support technique et les autres parties techniques soient représentés dans la définition et l'évolution des services.
• Offrir un service client.
• Maintenir la relation client.

 

Les compétences du Service Manager

Les compétences clés d’un Service Manager peuvent être identifiées suivant 2 catégories de compétences :

Compétences Commerciales

• Réflexion stratégique.
• Analyse commerciale.
• Délégation efficace.
• Gestion des risques.
• Priorisation et gestion du temps.
• Communication claire.
• Gestion de la relation commerciale.

Compétences Techniques

• Large compréhension technique.
• Gestion des niveaux de service.
• Ingénierie de service.
• Orientation client.

Manager-Ingénieur enthousiaste avec plus de 10 ans d’expérience en organisation, planification, direction et de contrôle des ressources au sein de diverses entités. Adrien est un spécialiste de la conduite du changement, il a réalisé divers projets transformationnels pour des petites et moyennes entreprises sociales.

 

Quelle est votre fonction actuelle ?

Je suis Chef de Programme basé en Afghanistan pour le Comité International de la Croix Rouge. Le Comité international de la Croix-Rouge (CICR) fournit une assistance humanitaire aux personnes touchées par un conflit ou une situation de violence armée.

 

Quelles sont vos missions ?

Mon travail consiste à délivrer des produits et des résultats (bénéfiques autant que faire se peut) via des projets techniques qui, pour la plupart, visent des hôpitaux et des prisons en Afghanistan. Notre but est de réduire la mortalité, la morbidité et la souffrance causées par la perturbation des services essentiels lors du conflit armé. Nous ciblons des populations affectées par le conflit en zone rurales et urbaines.

 

Comment êtes-vous arrivé à effectuer une carrière en gestion de projet ?

Lorsque j’ai commencé ma carrière, diplôme d’ingénieur en poche, j’ai rapidement pris une position de chef de projet junior pour une ONG à l’international. Je faisais naturellement ce que je savais faire : des calculs et des dimensionnements. Mais projet par projet, et surtout en rejoignant le CICR, j’ai compris que l’essentiel se trouvait ailleurs pour un chef de projet. Et que ce soit en équipe ou en individuel, je me suis souvent efforcé à combler mes lacunes plutôt que de renforcer mes capacités ce qui a ses avantages et ses inconvénients. Ma certification en gestion de projet m’a offert une méthode avec laquelle je pouvais naviguer facilement sur mes projets. Aujourd’hui j’aborde les projets dans des milieux complexes plus facilement.

 

Quels sont les plus gros problèmes/challenges que peut rencontrer une ONG au cours de projets ?

La plupart des problèmes rencontrés sur les projets portés par une organisation humanitaire sont les mêmes que pour n’importe qu’elle autre organisation, néanmoins, leurs intensités varient considérablement selon les contextes.

Ils sont donc souvent autour de la gestion des parties prenantes (80% de mon travail !) des ressources disponibles, et de l’accès à l’information.

Sur ce dernier point, lorsque nous n’avons pas accès aux populations affectées par le conflit - par exemple pour des raisons de sécurité -  nos challenges peuvent prendre des proportions considérables.

Le recours aux technologies à distance n’est souvent pas un moyen de faire face à la détérioration de la situation en matière de sécurité et d’accès (un simple téléphone ou appareil photo peut être rédhibitoire et vous entraîner dans une spirale infernale de suspicion et de manque de confiance). Par ailleurs, il peut participer à notre éloignement physique des communautés affectées par le conflit.

 

Comment le recueil « Change management body of knowledge » vous a-t il aider dans votre quotidien ?

Ce livre est remarquable. Il est aussi très dense (je n’ai pas encore tout lu !). Il n’offre pas de méthode mais m’a permis de structurer mes idées autour du changement. Il est facile à comprendre et, de mon point de vue, se marie bien avec le PMBOK.

Dans mon travail, j'aspire à faire en sorte que les solutions soient conçues et livrées tout en étant efficacement adoptées et utilisées ; et de ce point de vue le change management m’est essentiel.

En général, nous souhaitons que nos projets/programmes aient un impact positif sur les populations que nous ciblons, mais je trouve que notre attention se focalise trop souvent et trop rapidement sur les livrables eux même. Le change management se penche davantage sur cette composante soft qui est pour moi indispensable au succès de nos projets. Si hier, la composante «change» de mes projets se réduisait à une simple formation, aujourd’hui je fais beaucoup plus attentions aux cultures organisationnelles et aux réelles motivations des parties prenantes par exemple.

 

Quelles sont pour vous les clés du succès d'un projet international/humanitaire? 

Humilité et persévérance, méthode et écoute.

Citez trois notions que vous souhaiteriez apprendre dans un proche avenir pour vous développer en tant que professionnel ?

• La négociation : compte tenu de l’importance de la gestion des parties prenantes dans mon travail, la négociation (avec une dimension interculturelle en particulier) m’intéresse énormément.
• La gestion de programme : Renforcer mes compétences en gestion de programme (qui s’allie bien avec le change management) 
• L’élaboration de stratégies :  Très importante dans mon quotidien, c’est également une mes priorités.

 

Adrien Moreau

Manager-Ingénieur enthousiaste avec plus de 10 ans d’expérience en organisation, planification, direction et de contrôle des ressources au sein de diverses entités. Adrien est un spécialiste de la conduite du changement, il a réalisé divers projets transformationnels pour des petites et moyennes entreprises sociales. C'est également un négociateur accessible, il aspire à faire en sorte que les solutions soient conçues, développées et livrées tout en étant efficacement adoptées et utilisées.

Suivez Adrien sur Linkedin