Actualité

Dans notre précédent article de blog “Chaîne de valeur des services, système de valeur des services et flux de valeur", nous avons expliqué les concepts clés d’ITIL 4 et les 6 principales activités de la chaîne de valeur. Nous allons maintenant aborder le thème du contrôle, lié aux activités Plan et Improve, qui représentent les deux aspects spécifiques de la chaîne de valeur sur lesquels se concentre l'un des modules ITIL 4, à savoir ITIL Strategist Direct Plan and Improve.  

Contrôle 

ITIL 4 intègre le concept de «gouvernance partagée», qui dissipe le mythe selon lequel la gouvernance est liée au sommet d'une organisation. Diriger une organisation peut s'appliquer à plusieurs niveaux, chacun a sa propre autorité : de fait chaque personne a un périmètre de contrôle qu’elle gouverne, sur lequel elle a sa propre autorité, dirige ses actions et définit quels sont les résultats. ITIL souligne qu'au-delà de ce périmètre de contrôle, les personnes ont également un périmètre d'influence, c'est-à-dire que les ressources peuvent encore influencer les décisions prises par les autres.  

Comment effectuer le contrôle selon ITIL 4 ?

Une cascade de métriques doit être conçue et créée à partir de la finalité et des objectifs que nous nous sommes fixés, puis en définissant les indicateurs nécessaires et les métriques qui les soutiendront.  

Comment concevoir une cascade métrique ?

Souvent, nous partons d'outils et nous collectons des informations parfois inutiles. Au lieu de cela, ITIL 4 part des objectifs et définit ensuite les indicateurs et les métriques. La conception du système de mesure en cascade se fait (de haut en bas sur l’image) : de la finalité aux métriques. Bien sûr, les mesures permettant les métriques alimenteront les indicateurs, qui soutiendront les objectifs et la finalité de notre besoin (de bas en haut sur l'image). Puisque cela n'a pas de sens que toutes les décisions soient prises au même niveau hierarchique (sinon le processus décisionnel devient lent), il faut se construire une autorité généralisée en allant déléguer le plus possible mais en fournissant, à travers une cascade métrique, les outils pour que chacun à son niveau dispose des informations nécessaires pour prendre la meilleure décision dans un contexte précis. Si le périmètre du contrôle est trop étroit, les décisions auront tendance à être prises par la direction, ce qui doit être évité. Si, en revanche, le périmètre du contrôle est trop large, il y a un risque de prendre des décisions stratégiques à des niveaux organisationnels inférieurs. D'une part, un contrôle strict conduit à une escalade et donc à des délais plus longs, d'autre part, un contrôle moins restreint pourrait conduire à des prises de décisions comportant des risques qui ne sont pas rigoureusement évalués. Il faut donc essayer de tempérer les risques en formant les personnes ou en donnant des lignes directrices pour que les décisions soient conscientes et structurées. Le module ITIL 4 Direct, Plan and Improve fournit les compétences pratiques nécessaires pour créer une organisation informatique en amélioration continue, avec une direction stratégique forte et efficace. ITIL DPI fournit une méthode pratique de planification et de mise en œuvre de l'amélioration continue avec l'agilité nécessaire. ITIL® est une marque déposée d'AXELOS Limited, utilisée avec l'autorisation d'AXELOS Limited. Tous les droits sont réservés.

Comme décrit dans le Guide Scrum, il existe trois rôles principaux dans Scrum, responsables de la réalisation des objectifs du projet : le Product Owner, le Scrum Master et l’équipe de développement.  

Product Owner : Définition 

Le Product Owner est le professionnel responsable de maximiser la valeur du produit résultant du travail de l'équipe de développement ou, en d'autres termes, de maximiser la valeur pour le projet. Il est responsable de l'articulation des exigences du client et de la justification commerciale tout au long du projet. Nous pouvons dire que ce rôle incarne la voix du client.  

Le rôle du Product Owner Scrum

Le Product Owner est la seule personne responsable de la gestion du Product Backlog. La gestion du backlog produit comprend :

• L’expression claire des éléments du backlog produit
• L’ordonnancement des éléments dans le backlog produit pour mieux réaliser les objectifs et les missions
• L’optimisation de la valeur du travail effectué par l'équipe de développement
• L’assurance que le backlog produit est visible, transparent et clair pour tous, et montre sur quoi l’équipe de développement travaillera prochainement
• L’assurance que l'équipe de développement comprend adéquatement les éléments du backlog produit.

Le Product Owner est une personne, et non un comité. Le Product Owner peut représenter les désirs d’un comité dans le backlog produit, mais ceux qui veulent changer la priorité d’un élément du backlog produit (Product backlog Item PBI) doivent consulter le Product Owner. Les décisions du Product Owner sont visibles dans le contenu et l’ordonnancement du backlog produit, l'équipe de développement travaille selon ces exigences définies. Afin que le Product Owner réussisse dans sa démarche, il est fondamental que toute l'organisation respecte ses décisions.  

Les responsabilités du Product Owner

Le Product Owner représente les intérêts des parties prenantes auprès de l'équipe Scrum. Il doit entre autres :

• Assurer une communication claire des exigences de fonctionnalité du produit ou du service à l'équipe Scrum
• Définir les critères d'acceptation et s'assurer que ces critères sont respectés

Le Product Owner doit toujours maintenir une double vision, comprendre et soutenir les besoins et les intérêts de toutes les parties prenantes, tout en intégrant les besoins et le fonctionnement de l'équipe Scrum. Voici les responsabilités spécifiques du Product Owner Scrum:

• Définir la vision du projet
• Aider à créer la charte de projet et le budget du projet
• Identifier les parties prenantes
• Aider à déterminer les membres de l’équipe Scrum et le Scrum Master
• Aider à développer un plan de collaboration
• Aider à développer le plan de Team Building avec le Scrum Master
• Créer des Epic(s) et des Personas
• Hiérarchiser les éléments dans le backlog produit
• Définir les critères “DONE”
• Créer un plan de release
• Aider à créer des user stories
• Définir des critères d'acceptation pour chaque user story
• Clarifier les user stories
• Travailler avec l’équipe Scrum pour réaliser les user stories
• Expliquer les user stories à l'équipe Scrum lors de la création de la liste des tâches
• Fournir des conseils et des clarifications à l'équipe Scrum dans l'estimation de l'effort pour les tâches
• Clarifier les exigences de l'équipe Scrum lors de la création du sprint backlog
• Clarifier les exigences métier à l'équipe Scrum
• Accepter / rejeter les livrables
• Fournir les feedbacks nécessaires à l’équipe Scrum et au Scrum Master
• Mettre à jour le plan de release et le backlog produit priorisé
• Participer au déploiement des versions de produits et les coordonner avec le client
• Participer aux rétrospective de sprint
• Obtenir les ressources financières tout au long du projet

 

Les compétences du Product Owner

Le Product Owner doit être un expert du cadre de travail Scrum, connaissant les processus Scrum. Il/elle doit également avoir une connaissance du domaine des affaires et d'excellentes compétences en communication. Il existe d'autres compétences générales importantes, mises en évidence par le Guide Scrum :

• Capacité à gérer les incertitudes
• Techniques de négociation
• Approachable
• Proactif
• Décisif
• Pragmatique
• Orienté vers les objectifs.

Sources: scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf2

Holyvia est consultante senior pour une société de conseil en transformation digitale et intervient depuis quelques années en tant que Agile Business Analyst auprès de grands groupes internationaux.  

Quelle est votre fonction actuelle, quelles sont vos missions ?

Je suis consultante senior SI dans une société de conseil en transformation digitale. Mes missions changent à peu près tous les 1 an et demi/2 ans. En ce moment, j’interviens en temps qu’Agile Business Analyst auprès de la direction de Renault, je les aide et accompagne sur un projet de définition d’un outil qui va gérer toutes les applications de leurs concessionnaires.  

Comment êtes-vous arrivée à effectuer une carrière dans la gestion de projet et l’agilité ?

J’ai eu un parcours assez contrasté, j’ai obtenu mon diplôme d’ingénieur en électronique et informatique à l’ECE Paris mais je ne souhaitais pas m’orienter vers le métier de développeur, je recherchais quelque chose de plus fonctionnel. J’ai commencé en tant qu’assistante à maîtrise d'ouvrage où, au cours de mes sept années d’expérience, j’ai pu acquérir diverses compétences notamment sur la gestion des besoins. Depuis deux ans, dans la continuité de mon parcours, je suis devenue business analyst.  

Il n’existe pas une seule définition pour le poste de business analyst mais plusieurs réalités selon l’entreprise où il/elle exerce ses fonctions. Quelle serait votre définition/rôle ?

Comme vous l’avez dit, il n’existe pas de définition arrêtée du métier de business analyst et ce n’est pas toujours facile pour nous de nous définir. Au départ le rôle est assez flou. Principalement nous sommes présents là où il y a besoin de nous. C’est ma deuxième mission en tant que business analyst et ce que je retiens principalement du rôle de business analyst c’est qu’il peut être comparé à un couteau suisse. Il/elle doit avoir diverses compétences afin d’aider le Product Owner, le chef d’équipe et l’équipe technique sur des projets Agile. Il faut à la fois savoir analyser les situations, savoir faire exprimer un besoin au client, savoir présenter une solution, savoir orienter l’équipe technique, épauler le Product Owner… Le business analyst est vraiment multitâches. C’est également mon rôle de lever une alerte si les user stories sont mal écrites, si il en manque ou si le Product Owner est débordé, il m’arrive de prendre la suite et de les rédiger pour lui. En clair, mon rôle est de travailler en soutien du Product Owner, tout en étant proche de l’équipe technique et du chef d’équipe pour connaître ses besoins en terme de limitations techniques et avoir une vision à 360° sur chaque projet. Le business analyst doit donc se familiariser avec l’organisation du travail découlant des contraintes internes et externes de l’entreprise. Il peut acquérir ces connaissances organisationnelles en observant tous les contributeurs clés du projet, afin de s’approprier la manière dont l’utilisateur fonctionne dans le cadre de son environnement de travail et comprendre les liens et interactions entre les rôles et services de l’organisation. Les processus métiers sont bien entendu au centre de l’analyse, mais il faut répertorier également tous les éléments qui peuvent être impactés par ou impacter le projet. J’ajouterai même que le métier de business analyst est ouvert, ce n’est pas un métier figé. Comme le périmètre n’est pas toujours bien clair ni bien défini, c’est une opportunité pour le business analyst, selon sa mission, d’aller réinventer son métier et de redéfinir son périmètre (sans déborder sur celui des autres), en fonction des besoins, de ses compétences, de ses envies. Le business analyst a la possibilité de toujours aller plus loin pour participer, aider au mieux la réalisation du projet et découvrir de nouvelles choses. C’est là tout l’intérêt du métier.  

Quelles sont les problématiques/challenges que rencontrent les business analyst ?

Le challenge principal est cette complétude justement. On peut être un bon business analyst mais il est très difficile d’être complet, il y a forcément des lacunes ou des points faibles dans certains domaines. Par exemple dans tous les projets on va attendre de moi que je sache faire du SQL, des requêtes, ce qui n’est pas forcément mon quotidien. C’est à ce moment même qu’il est important de percuter rapidement, lorsqu’on me parle en langage technique, de me mettre à jour rapidement pour au moins comprendre les problématiques qui me sont adressées. Comme le business analyst est attendu sur tous les fronts, la réactivité fait la différence et permet non d’être excellent mais au moins efficace sur tous les fronts.  

Quelles sont pour vous les clés du succès pour être une excellente business analyst ?

Il faut être humble pour apprendre vite, ne pas avoir peur de dire qu’on ne sait pas. C’était peut-être un de mes points faibles au début mais aujourd’hui c’est devenu ma force. On est en mission sur des projets très compétitifs, où on attend beaucoup du consultant et cela peut faire peur de dire qu’on ne sait pas alors que justement si, il faut le dire mais surtout identifier et se rapprocher des bonnes personnes, qui seront capables de nous enseigner ou de nous laisser apprendre très rapidement. Le deuxième point qui rejoint le premier est l’écoute. Ecouter et apprendre vite puisqu’il n’y a rien de compliqué dans le fond mais dans un projet il faut savoir percevoir d’emblée quelles sont les personnes qui peuvent me faire apprendre et quelles sont celles que je dois aider, et qu’est-ce que je dois faire concrètement.  

Qu'en est-il du travail Agile et à distance, comment votre entreprise a-t-elle géré la situation en matière de COVID?

Je l’ai vécue comme une expérience très intéressante, qui a prouvé que même si le contact humain est agréable, nous n’avions pas spécialement besoin d’être physiquement présent dans le même espace pour travailler et échanger. Nous avons continué à avoir nos réunions et cérémonies (daily meeting, sprint review) à distance à l’aide de l’application de communication collaborative Microsoft Teams, qui propose également un tableau blanc interactif sur lequel il est possible de recréer des post-its, dessiner, écrire des notes ou encore créer des schémas complexes. Nous n’avons pas rencontré de problèmes particuliers de communication ou autre. Cela dépend vraiment des projets mais comme notre équipe technique est à l’international, nous avions déjà l’habitude de travailler à distance. L’équipe sur place, elle, s’est très bien adaptée en augmentant le nombre de mini visio durant la journée.  

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

Dans un proche avenir j’aimerais me pencher sur la gestion de projet. En tant que business analyst, nous voyons beaucoup de choses, on apprend également beaucoup de choses, par conséquent on a envie d’avoir le poste qui va avec cette expérience acquise et qui permet d’avoir un regard à hauteur du projet. Ensuite je m’intéresse énormément à la stratégie d’entreprise, qui requiert une bonne capacité analytique, afin d’aider soit des entreprises, des dirigeants ou directement des gros projets à savoir comment se définir, s’embarquer sur un marché.  

Holyvia Joseph

Holyvia est consultante senior pour une société de conseil en transformation digitale et intervient depuis quelques années en tant que Agile Business Analyst auprès de grands groupes internationaux. Suivez Holyvia sur Linkedin

Un niveau élevé d'engagement des personnes qui ont besoin de changer leur façon de travailler est essentiel dans un changement organisationnel pour un retour clair sur tous les efforts et investissements consacrés à ce changement.  

Documents standard de facto dans de nombreuses méthodes de changement

Dans de nombreuses méthodes de conduite du changement, en particulier celles qui sont plus axées sur le cycle de vie et les processus, comme MSP (5.) et Agile Change Management (1.), des techniques sont proposées pour saisir ce qui doit être changé, la raison du changement et comment le changement est lié à cette raison. Ces techniques consistent souvent à mettre quelque chose sur papier et aboutissent généralement à l'un de ces types de documents :

• Une vision : une description courte, de haut niveau et motivante d'un état futur souhaité, qui explique où nous voulons aller et les raisons, et est utilisée à des fins de communication.
• Un schéma directeur : une description plus détaillée de cet état futur souhaité, qui peut être un modèle POTI, un modèle opérationnel cible ou “Target Operating Model”, un Business Model, un modèle 7S, une description Copafith, etc., et qui peut être utilisée pour être comparée à l'actuel «Tel quel», pour identifier plus en détail les changements nécessaires.
• Des exigences : descriptions sous une forme ou une autre des extrants ou des «livrables» nécessaires pour pouvoir mettre en œuvre le changement. Cela peut prendre la forme d'épopées, de user stories, d'exigences fonctionnelles, de descriptions de produits, etc.
• Une cartographie des bénéfices : un modèle, une carte ou une visualisation qui explique le lien entre l'objectif final du changement, les changements plus détaillés et les résultats nécessaires pour ce changement. Cela peut être une cartographie des bénéfices, un diagramme de dépendance des bénéfices, un arbre des objectifs, un diagramme des objectifs, un diagramme ishikawa, etc.

 

Utilisations typiques de ces documents : gouvernance, qualité, contrôle

Une vision, un schéma directeur, une cartographie des bénéfices et des exigences ne sont souvent utilisés que pour des raisons de gouvernance. Des exigences approuvées signifient que nous pouvons commencer à y travailler. Un schéma directeur approuvé signifie que la direction a accepté et a donné le feu vert. Cependant, cela ne signifie pas que les personnes qui doivent changer leur façon de travailler sont motivées. Ces documents, s'ils sont bien préparés, améliorent intrinsèquement la qualité des préparatifs d'une initiative de changement. Un schéma directeur cohérent garantit que nous n'avons rien oublié, une bonne présentation de la vision aide à communiquer et à créer une compréhension commune du changement. Des exigences bien rédigées aident à obtenir les bons résultats et des bénéfices bien définis aident à évaluer le succès d'un changement. Pourtant, pour susciter l'engagement dans le changement, la qualité technique seule ne suffit pas. Le suivi et le contrôle des progrès sont d'autres utilisations importantes de ces documents, mais lorsqu'ils sont utilisés uniquement à cette fin, ils pourraient en fait contrecarrer nos efforts pour accroître l'engagement. La vision et la cartographie des bénéfices ne doivent pas être utilisées uniquement pour la gouvernance, pour améliorer la qualité ou pour le suivi et le contrôle, mais aussi pour accroître l'engagement.  

Augmenter l'engagement au changement avec une vision et une cartographie des bénéfices

Pour accroître l'engagement avec ces documents, examinons les 3 facteurs de Dan Pink pour augmenter les performances et la satisfaction : l'autonomie, la maîtrise et la finalité :

• Autonomie : le désir de diriger nos propres vies. Cela augmente l'engagement plus que la conformité.
• Maîtrise : l’aspiration de se surpasser sur quelque chose qui compte.
• Finalité : l’envie de faire quelque chose qui a du sens et est important. Les entreprises qui se concentrent uniquement sur les bénéfices sans valoriser leur objectif se retrouveront avec un service client médiocre et des employés mécontents.

De toute évidence, un énoncé de vision bien rédigé donne une finalité au changement dans son ensemble. Si une vision est bien comprise et définit une finalité partagée par toutes les personnes impliquées, elle contribue davantage à la performance et à la satisfaction, et par conséquent à l'engagement. Maintenant, même si une vision donne une finalité au changement dans son ensemble, elle n'explique pas automatiquement la finalité des activités de changement plus détaillées et des résultats aux personnes impliquées, qui sont invitées à faire plus que leurs efforts habituels. C'est bien sûr là qu'interviennent le schéma directeur et la cartographie des bénéfices : ils relient les changements et les résultats plus détaillés à fournir à l'objectif supérieur de l'énoncé de vision. En fin de compte, si les personnes impliquées comprennent et partagent l'énoncé de vision, (leur part dans) le schéma directeur, la cartographie des bénéfices et les exigences, elles auront une vision claire, de leurs activités de changement personnel, à l'objectif global du changement. Et cela donne également une finalité à leurs activités personnelles. Le facteur “maîtrise” cité par Dan Pink devrait également être intégré dans les documents mentionnés. En particulier, les bénéfices devraient être liés à des facteurs personnels d'amélioration. Des bénéfices bien définis sont SMART : spécifiques, mesurables, atteignables, réalistes et temporellement définis, et devraient en même temps être personnellement réalisables et personnellement pertinents. Je dirais même un peu stimulant, ambitieux et intéressant. L'utilisation de KPI ou “balanced scores” comme mesures des bénéfices liés à la maîtrise personnelle, dans les bonnes conditions, contribuera à augmenter les performances, la satisfaction et l'engagement dans un changement. Il est important, pour créer les bonnes conditions, que l’anxiété d’apprentissage de Schein soit prise en compte et un environnement sûr doit être créé, où les gens peuvent se sentir en sécurité, même s’ils ne peuvent pas (immédiatement) atteindre leurs objectifs de bénéfices personnels ou ceux de leurs services. Enfin, le facteur d’autonomie cité par Dan Pink indique que stimuler et responsabiliser les personnes impliquées, non seulement dans la mise en œuvre du changement, mais dans la définition des changements nécessaires, nécessite une approche aussi participative que possible lors de la définition de la vision, du schéma directeur, de la cartographie des bénéfices et des exigences. Plus les personnes sont impliquées dans la définition de ces documents et ont leur mot à dire, (c.-à-d l'autonomie), plus ils ressentiront la finalité et la maîtrise sur le plan personnel.  

Limites

«Participer… autant que possible» peut sembler vague. Il y a deux situations qui vaillent la peine d’être mentionnées et qui limitent l'approche participative :

• Le travail de Dan Pink sur l’autonomie, la maîtrise et la finalité est particulièrement pertinent pour les personnes qui font un «travail de connaissance». Il affirme que dès lors que le travail requiert plus que «des compétences cognitives rudimentaires» (3), ces trois facteurs deviennent de plus en plus importants pour motiver les gens. Avec des personnes effectuant un travail purement physique, les trois facteurs sont moins pertinents. Dans la pratique, cependant, le travail de connaissances devient de plus en plus important dans tous les secteurs d’activité, tout comme les trois facteurs de motivation de Dan Pink.
• Changement d'urgence : les situations «changer ou mourir» exigent de la rapidité et limitent la possibilité de participation à l'initiative de changement. Bien entendu, si une organisation se trouve dans une telle situation, le but du changement dans son ensemble sera également plus clair. Cependant, cela ne signifie pas que les personnes comprennent en quoi ce qui leur est demandé personnellement est lié à cet objectif plus vaste. Surtout si on leur demande de subir les conséquences (parfois désastreuses) d'un changement d'urgence. Un faible engagement et un retour sur investissement plus faible du changement sont les résultats logiques, ce qui n'est qu'une des raisons pour lesquelles la direction devrait essayer d'éviter de tels changements d'urgence.

 

Conclusion

En résumé, pour susciter l'engagement des personnes aux changements non urgents qui impliquent des compétences cognitives rudimentaires:

• Veillez à ce que la finalité du changement dans son ensemble soit partagée et comprise, et reliez les activités de changement personnel à cet objectif, en utilisant un énoncé de vision clair et une cartographie des bénéfices.
• Assurez-vous que les bénéfice soient SMART, (spécifiques, mesurables, atteignables, réalistes et temporellement définis) certes, mais aussi pertinents et ambitieux (suffisamment) au niveau personnel; et créez un environnement sûr.
• Donnez l’occasion, aux personnes qui doivent changer leur façon de travailler, de participer autant que possible à la création de l'énoncé de vision, du schéma directeur, de la cartographie des bénéfices et des exigences.

Ajoutez finalité, maîtrise et autonomie à votre cartographie des bénéfices et votre vision !  

Plus d’informations

Si vous êtes intéressé par la conduite du changement et souhaitez découvrir comment préparer un énoncé de vision, un schéma directeur, une cartographie des bénéfices, découvrez nos formations Change Management® et MSP®, sur le guide de changement transformationnel! MSP® is a registered trademark of AXELOS Limited.  

Références

1. Franklin, M. (2014), Agile Change Management, Kogan Page Ltd, London, UK
2. Kotter, J.P. (2007), Leading Change, Why Transformation Efforts Fail, HBR, Jan. 2007, HBSPC, Brighton, USA
3. Pink, D., (2009), The Surprising Truth About What Motivates Us, Riverhead Books, New York, USA
4. Smith, R. et al (ed.), (2014), The Effective Change Manager’s Handbook, Kogan Page Ltd, London, UK
5. Sowden, R. et al, Crown Copyright, (2011), Managing Successful Programmes, TSO, Norwich, UK

 

Niels Van Bemmelen

Niels a plus de 20 ans d’expérience dans la gestion de projets, programmes et du changement au sein des organisations. Il a été impliqué dans de vastes projets de transformation d’entreprise dans des environnements internationaux hautement compétitifs. En tant que chef de projet et business analyst, Niels a travaillé sur des projets dans les secteurs financier, touristique, éducatif et également dans le secteur public. Il est formateur multilingue pour PRINCE2, MSP, MoP, P3O et PRINCE2 Agile et peut dispenser des cours en anglais, italien et néerlandais. Suivez Niels sur Linkedin  

Vous trouvez une offre d’emploi qui vous attire et souhaitez postuler… mais comment mettre en valeur vos certifications ?

Les certifications peuvent être utiles pour faire ressortir votre candidature lors du processus de recrutement. Que vous ayez une longue carrière, plusieurs diplômes ou masters, ou des formations professionnelles qui ont abouti à des certifications professionnelles, il existe de nombreuses façons d'inclure ces certifications sur un CV pour attirer l'attention du recruteur.

Les certifications professionnelles démontrent une certaine passion du candidat, un intérêt particulier pour l'industrie, ou le métier dans lequel il évolue et sont la preuve d'une expertise et de compétences spécifiques.

Dans un premier temps, vous devez évaluer vos différentes certifications et décider pour chaque certificat si oui ou non il est pertinent et suffisamment significatif pour être inclus sur votre CV pour la position en question.

De toute évidence, si dans l’annonce il est explicitement écrit que l’entreprise recherche un profil ayant obtenu telles certifications et que le recruteur ne trouve pas ces certifications essentielles pour l'emploi sur votre CV, vous risquez d’office de ne pas être retenu. D’où l’importance de bien mettre en évidence vos certifications professionnelles.

N’importe quelle certification peut faire briller votre CV et constituer l’élément qui fait la différence. Il existe cependant des règles pour mettre en valeur vos certifications sur votre CV.

 

Où mettre mes certifications sur les CV ?

Si elles sont critiques pour l'emploi, vous pouvez les insérer à quatre endroits :

1. Après votre nom
2. En haut dans votre présentation/-résumé de CV
3. Dans une section spéciale certifications
4. Dans votre section expérience professionnelle

Si ce n'est pas le cas, dans une section certifications, sous la section formations.

 

Quelles informations dois-je insérer ?

La certification est un document qui prouve que vous avez acquis une compétence spécifique et est délivré par un organisme accrédité. Lorsque vous ajoutez une certification sur votre CV, spécifiez les informations suivantes:

Nom de la certification

• Nom du centre ou de l'autorité de certification
• Date d'obtention

NB. N'oubliez pas que les certifications valides sont délivrées uniquement par un tiers disposant d'une licence appropriée.

 

Comment lister une certification en cours sur le CV

Vous pouvez inclure une certification en cours d'acquisition sur votre CV, si celle-ci est essentielle pour le job convoité, en ajoutant la mention «en progrès», «en cours», à la description et en précisant la date d'achèvement prévue.

 

Est-ce que je peux inclure une certification expirée sur un CV ?

Il n'est pas acceptable de lister les certifications anciennes ou expirées sur un CV. Si vous avez une certification ayant une date d'expiration possible, il est essentiel que vous renouveliez votre certification avant cette date afin de l'inclure sur votre CV.

Enfin, il est très important de ne pas inclure de certifications que vous ne possédez pas, c'est-à-dire qu'il est fortement déconseillé de mentir sur un CV !

 

Comment inclure ma certification sur mon profil Linkedin ?

Il est possible d'ajouter votre certification sur votre profil Linkedin. En effet, les certifications constituent un excellent moyen de mettre en avant vos connaissances et réussites professionnelles également sur votre profil LinkedIn. Voici le lien pour connaître la démarche: https://www.linkedin.com/help/linkedin/answer/45254/ajouter-modifier-ou-supprimer-des-certifications-sur-votre-profil?lang=fr

Vous pouvez également directement ajouter votre certification en cliquant sur le bouton suivant :

 

Conseil

Lorsque vous suivez une formation ayant différents niveaux de certifications, par exemple PRINCE2, qui propose les certifications PRINCE2 Foundation et PRINCE2 Practitioner :

• Si vous obtenez le niveau Practitioner, écrivez PRINCE2 Practitioner
• Si vous obtenez uniquement le niveau Foundation, écrivez PRINCE2 (sans préciser Foundation)

Ainsi votre certification garde son effet positif auprès des recruteurs et démontre que vous avez la maîtrise des bases de la méthode.

 

Agile est souvent utilisé pour gérer des projets informatiques, mais il peut également être adopté dans des projets non informatiques. Il existe de nombreux exemples de projets non informatiques pouvant être gérés avec Agile : un projet peut être géré avec Agile si les produits / livrables peuvent être produits et déployés dans de courtes périodes de temps, et peuvent subir des changements en raison de mises à jour et de changements des exigences requises.  

Quelles sont les caractéristique d’un projet Agile réussi ?

• Les sprints (ou itérations) durent de 4 à 12 semaines.
• La communication directe est plus importante que la documentation, l’important est de livrer un produit, pas la documentation du produit.
• Les membres de l'équipe travaillent dans le même environnement ou utilisent des outils virtuels pour travailler ensemble.
• Il y a un sponsor 100% dédié au processus Agile.
• Des changements dans les exigences du produit sont prévus.

  Bien sûr, il existe d'autres caractéristiques fondamentales pour la réussite des projets agiles qui sont également en commun avec les projets traditionnels :

• Le cycle de vie du projet est suivi et accepté par tous.
• Les exigences sont bien comprises.
• La planification est gérée, suivie et partagée.
• Il y a une équipe dédiée.
• La communication avec les parties prenantes est essentielle.

Choisir le bon projet

L'un des facteurs de succès les plus importants d’Agile est la sélection du BON projet, dans lequel utiliser les méthodes agiles. Pour choisir le bon projet agile, vous devez vous assurez que :

• Vous devez livrer un produit de qualité rapidement, mais vous n'êtes pas obligé de tout livrer en même temps.
• Vous vous attendez à ce que les exigences changent ou évoluent.
• Votre organisation est prête à laisser certains membres de l'équipe prendre des décisions indépendantes sur le produit en cours de fabrication.
• Vous êtes convaincu que le produit peut générer de la valeur pour l'entreprise de manière incrémentale.

  Vous souhaitez implémenter une “méthode” Agile mais vous ne savez pas laquelle choisir entre AgilePM et Scrum ? Consultez notre article AgilePM vs Scrum !