articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Faire des rapports et prendre des décisions sur votre projet est bien plus aisé avec Project qu’avec Excel. Une seconde vidéo humoristique de notre partenaire Microsoft qui met en évidence certains des avantages à quitter Excel pour un outil dédié au management de projet.
Une première vidéo humoristique de notre partenaire Microsoft 🙂 . Elle met en évidence certains des avantages à quitter Excel pour un outil dédié au management de projet et donc bien plus puissant tout en restant simple. En effet, Project permet d’opter pour une planification totalement manuelle si nous le souhaitons.
En analysant de plus près nos méthodes de développement, maturité des équipes et autres facteurs, le rapport CRASH nous confirme que nous sommes sur la bonne voie même s’il reste encore des choses à améliorer. Nos pratiques de développement et de livraison de nos projets informatiques et technologiques évoluent positivement !
Vous pouvez télécharger le rapport complet ici.
Avant que la Collaboration Sociale ne fasse son apparition, le quotidien d’un chef de projet était accaparé par les voyages et les appels téléphoniques afin de coordonner les membres de son équipe et de piloter son projet. Aujourd’hui, les choses ont bien changé.
Cette nouvelle édition du livre blanc raconte de manière ludique la journée d’un chef de projet du XXIe siècle, utilisant toutes les technologies Microsoft pour mieux organiser son travail quotidien et ses projets : Office 365, Delve, Project Online, SharePoint, Skype for Business, Yammer ou encore Office Groups, Planner et Wunderlist.
Télécharger le livre blanc (3.3 M)
Beaucoup d’attention est portée au « Manifeste Agile » et bien qu’il soit une composante importante de Agile, ce n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent comment nous percevons et implémentons les pratiques Agiles…
Ceci est l’aspect le plus important d’Agile qui doit être compris et adopté comme une partie de la culture de toute organisation qui veut être « Agile » : le client et l’utilisateur final sont le focus ultime du processus tout entier, du commencement jusqu’à la fin. Le client est le juge du succès ou de l’échec d’un produit ou d’une fonctionnalité, pas la société ni ses parties prenantes. Le client est celui avec les problèmes que nous adressons et comme tel il doit être partie intégrante du processus de développement de produit du commencement à la livraison.
Ignorer vos clients jusqu’à ce que votre produit soit prêt à être expédié est l’anti-modèle Agile numéro 1 dans le monde.
La deuxième partie la plus importante de Agile est en fait… …de faire preuve d’agilité. N’importe quelle organisation qui investit lourdement dans la définition en amont, la conception et la définition des besoins n’est Pas Agile…et ne fait certainement pas preuve d’agilité. Tout le point de l’agilité est que vous pouvez vous accommoder d’importants changements de besoins à n’importe quel point du processus et toujours livrer quelque chose qui est utile pour le client et résout un ou plusieurs de leurs problèmes. Des processus agiles s’appuient sur la Priorisation et non par la Négociation de contrat pour atteindre le succès. Quand de nouveaux besoins surviennent, ils ne sont pas soumis à de lourds et détaillés processus de management des changements. Ils sont plutôt ajoutés à la pile de tout le reste à faire et évalués tout simplement comme une autre tâche ou histoire utilisateur déjà dans le processus.
Penser que les choses sont totalement ou presque entièrement définies à l’avance est un autre anti-modèle Agile dont beaucoup de sociétés souffrent fréquemment.
Il y a plusieurs choses dans ce principe. D’abord du logiciel qui marche est le but du processus à chaque étape, ensuite le travail devrait être itératif et s’améliorer à chaque livraison et, finalement les itérations qui sont engagées devraient être les plus courtes possible. Si vous travaillez sur un projet qui progresse pendant six mois sans vérifier les résultats intermédiaires avec le client (ou son représentant), vous n’êtes pas Agiles. Si vous travaillez sur des itérations d’une semaine, mais ne livrez pas quelque chose qui résout au moins un problème client à chaque itération, vous n’êtes pas Agiles. Les itérations agiles doivent être assez longues pour livrer un logiciel qui fonctionne et assez courtes pour vous assurer que ce que vous livrez résout bien dans les faits des problèmes clients.
Travailler itérativement ne signifie pas nécessairement que vous êtes Agiles; l’itération est importante, mais livrer un logiciel qui fonctionne l’est tout autant.
La collaboration et les interactions entre les gens sont critiques au succès de toute organisation Agile. Les silos et le « jeté de besoins par-dessus le mur » sont contre-productifs aux approches Agiles, comme l’est de segmenter votre organisation entre les gens « du métier/business » et les « techniciens ». Tout le monde du côté « métier/business » devrait être prêt, consentant et disponible pour fournir autant de support que possible aux équipes « techniques » et vice versa. L’idée séculaire qu’il y a une certaine différence inhérente entre la façon dont « l’activité business » devrait être exécutée et la façon dont « la technologie » devrait l’être est entièrement artificielle et contre-productive dans un âge d’innovation rapide et de livraisons encore plus rapides.
Décourager la collaboration ou encourager le « silotage » des efforts est un anti-modèle Agile qui persiste dans trop de cultures d’entreprise.
Agile valorise les personnes en tant que personnes et les équipes en tant qu’équipes. Les gens ne sont pas des rouages interchangeables que vous pouvez aléatoirement déplacer d’un projet à un autre et vous attendre à ce qu’ils excellent continuellement. Les individus sont motivés par des choses différentes et dans une vraie approche Agile nous exploitons ce qui motive individuellement les membres de notre organisation pour créer des équipes avec ces individus motivés qui sont intrinsèquement motivés pour réussir. Agile déboute de l’idée que la récompense extrinsèque fournit des résultats exceptionnels et se concentre plutôt sur l’assurance que les individus aient la motivation, l’environnement et les outils dont ils ont besoin pour réussir tout seuls. Il n’y a aucune approche de type « la carotte et le bâton » dans Agile. Il y a des problèmes à résoudre pour les clients qui sont intéressants et fascinants et qui sont résolus par des personnes qui ont l’intérêt nécessaire et la motivation intrinsèque pour les résoudre.
Attendre des gens d’être performants simplement parce qu’ils sont membres « d’une équipe » et non pas parce que cette équipe partage la motivation intrinsèque de réussir est un anti-modèle extrêmement commun dans les grandes organisations.
La méthode séculaire d’avoir un unique expert du sujet qui écrit tout qu’il veut avoir et le remet aux développeurs comme « une liste à exécuter » de besoins est hérétique aux approches Agiles. Des personnes différentes pensent et communiquent différemment et le texte écrit est l’une des pires façons d’exprimer que vous essayez de dire. Au pis-aller, c’est vague et difficile à déchiffrer pour la personne qui ne l’a pas écrit; au mieux, c’est un document clinique, stérile qui remplace le sentiment par la précision. Si le but est d’exprimer la douleur que ressent le client et motiver les équipes à exceller dans leur job parce qu’elles le veulent, alors aucune de ces approches par des besoins écrits n’aura le résultat que nous désirons. Nous utilisons plutôt des choses comme les Histoires Utilisateur, qui explicitent le problème que nous voudrions résoudre, mais qui permettent à notre équipe de développement d’utiliser sa créativité pour y répondre de la meilleure façon possible.
Même quand nous utilisons des outils pour suivre le travail et communiquer les informations les plus basiques, nous ne pouvons pas oublier que la façon la plus importante de communiquer l’un avec l’autre, indépendamment des rôles, est toujours la conversation en face à face.
Particulièrement dans le monde des grandes sociétés, nous aimons le concept que tout peut être mesuré, évalué et KPIsé. Nous suivons les revenus, des points d’histoire, la vélocité, la consommation, les nombres d’erreurs découvertes, Ad Nauseum. Pourtant nous oublions souvent que ce que nous essayons vraiment de faire est résoudre des problèmes pour les clients. Et aucune de ces mesures n’indique combien de valeur nous apportons en réalité ni si nous résolvons vraiment des problèmes clients. Le but final de chaque itération devrait être du logiciel qui marche, qui fait quelque chose que nous pensons être de valeur. Sans cela, c’est un échec. Quoi que ce soit de plus que cela est du glaçage sur le gâteau. Les équipes Agile se mesurent elles-mêmes sur si elles apportent réellement de la valeur et si elles créent vraiment quelque chose qui marche la fin de chaque itération.
Répétons ceci : la vélocité n’est pas la mesure du progrès. La consommation n’est pas la mesure de progrès. Les points d’histoire ne sont pas la mesure de progrès. La capacité n’est pas la mesure de progrès. Les délais ne sont pas la mesure de progrès. La seule chose qui importe est combien vous créez de logiciel qui marche.
Il y a cette idée fausse dans le monde, tenue tant par les développeurs que par des hommes d’affaires, que Agile signifie aucune documentation, que Agile veut dire faire quoi que vous ayez besoin de faire pour atteindre un but, que Agile signifie changer les priorités et équipes rapidement pour assurer une production maximale, que Agile rime avec imprévisibilité et manque de prédictibilité. Le fait est, l’un des buts principaux d’Agile est créer un environnement de prévisibilité, de stabilité et une allure constante et acceptable de développement de produits qui dure indéfiniment. Il n’y a rien dans les principes Agile qui écarte de créer des planning (quoique ces plans portent un peu d’incertitude !) ni d’être capable de prévoir quand quelque chose pourrait être livré. Au contraire, il n’y a rien dans les principes Agile qui s’attend à ce que des développeurs s’engagent dans des comportements de pression exagérée. En fait, de tels comportements sont de bien des façons antithétiques aux concepts Agiles : si votre équipe doit travailler beaucoup trop durement pour livrer quelque chose, vous avez manqué en amont à vos devoirs de priorisation efficace des Histoires Utilisateur.
Aucune vraie pratique Agile ne devrait aboutir à de l’épuisement, des périodes critiques, ni une incertitude constante et prolongée. Les anti-modèles aboutissent à ces comportements contradictoires.
Des équipes vraiment agiles ne rassemblent pas à la va vite de mauvais morceaux de code pour l’appeler « bon ». Elles prennent le temps et mettent les efforts nécessaires pour comprendre ce qu’elles essayent de réaliser, comment elles pensent pouvoir résoudre les problèmes et décomposer les choses en assez petits « morceaux » de travail pour à la fois itérer sur le problème et livrer des solutions potentiellement exploitables à chaque étape du projet. La majorité de ce travail se produit avant que les équipes ne s’engagent à faire le travail. Il y a là du pré-travail pour parler approches, pour discuter architecture et s’engager dans des discussions avec des représentants du métier, des parties prenantes et les équipes techniques. Nous nous référons souvent à ceci comme à des sessions de démarrage ou de préparation d’arriéré de produit mais Agile ne devrait jamais être une excuse pour la mauvaise qualité ou une conception erronée.
La conception erronée et de faibles standards aboutissent à de pauvres solutions qui ne répondent pas vraiment aux besoins clients; c’est un facteur de ralentissement, pas un facteur d’accélération.
Beaucoup trop de personnes lisent ceci de la mauvaise façon et limitent ainsi leur capacité à totalement s’engager dans des pratiques Agiles fortes. Simplifier vos buts, vos histoires, votre travail et tout le reste est un processus qui commence par l’opposé : une très large compréhension de ce que sont les buts et de comment ils pourraient être atteints. Le résultat de tels efforts n’est pas nécessairement un projet plus petit, mais des incréments plus petits et plus simples qui peuvent s’additionner en quelque chose de très grand et qui peuvent aussi indirectement réduire les buts globaux. Le plus grand obstacle est ici que le simple est plus difficile que le complexe, particulièrement quand les gens s’engagent dans des séances de remue-méninges, ce qui arrive souvent avec des équipes techniques. Résolvez le problème d’abord, itérez ensuite par petits morceaux.
« Rendez chaque détail parfait et limitez le nombre de détails à perfectionner. » Jack Dorsey
Le mot clé est ici « naissent ». Quand vous réunissez les bonnes personnes et que toutes sont alignées vers les mêmes buts, certaines choses se produisent. D’abord, elles se tiennent naturellement responsables, parce qu’il y a un sentiment intrinsèque de camaraderie et de but commun. Deuxièmement, Elles se supportent et en même temps se défient pour assurer que le résultat final respecte non seulement leurs attentes individuelles, mais aussi leurs attentes collectives qui sont presque toujours plus élevées. Et finalement, elles améliorent le tout par la collaboration : la valeur de n’importe quelle équipe auto-organisée est au moins 2 fois plus importante que la somme de ses parties individuelles. Le facteur clé est ici auto-organisation, qui peut être dure à vendre dans beaucoup d’organisations, mais les meilleures équipes ne sont pas celles assemblées par un cadre intermédiaire, ce sont plutôt des groupes de personnes qui ont choisi de s’aligner vers un but commun.
Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces, plus fortes et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.
Dans presque chaque organisation que j’ai observée face au défi d’implémenter les pratiques Agile, la plus grande chose qu’elle loupe est l’importance de l’amélioration continuelle ou continue. Agile a ses origines dans des concepts industriels LEAN : la valeur de l’individu, la primauté du résultat sur le processus et, plus important encore, le besoin de constamment mesurer, ajuster et améliorer comment vous faites ce que vous faites. Toute équipe qui veut ne pas s’engager dans les rétrospectives et les revues d’équipe avec leurs parties prenantes après chaque itération risque la stagnation et les anti-modèles parce qu’elle ne les voit jamais arriver. Beaucoup d’équipes voient ces sessions comme contre-productives, des pertes de temps, des exercices « soft skills » qui consomment seulement de leur temps d’exécution. Mais la plupart des équipes les évitent simplement par crainte (et le rationalisent comme elles le peuvent): la crainte d’être sur la sellette, la crainte d’accepter la responsabilité, la crainte de changement. La vérité vraie est que quand elles sont exécutées correctement, elles peuvent être les réunions les plus enrichissantes dans lesquelles les équipes s’engageront. Elles sont destinées à pousser les gens à constamment s’améliorer et être plus efficaces et il n’y pas de bonne raison de ne pas s’engager dans ces discussions.
L’absence de « regarder derrière soi » profondément et honnêtement pour évaluer comment une équipe avance et où elle peut s’améliorer est un anti-modèle fatal au succès de Agile sur le long terme.
Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser les choses les plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager un montant faible et raisonnable de dette technique peut en réalité faire avancer le projet plus rapidement et permettre d’atteindre l’objectif d’avoir un logiciel utilisable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la dette technique : « Comme toute dette dans la vie de tous les jours, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
Derek remarque aussi que tout comme toute dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre : Elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement l’équipe de support technique ou quelqu’un d’autre en aval.
Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui jetterait les dés pour décider de votre taux d’intérêt. Alors, si vous n’êtes pas obligés de prendre ce risque, ne le prenez pas.
Mais la dette technique est-elle vraiment une proposition de type tout ou rien, blanc ou noir ?
Quand elle considère la Dette Technique, une société doit déterminer combien devrait être investit pour y remédier. La meilleure façon de le faire est en donnant une valeur monétaire à la dette technique pour allouer une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques à rembourser cette dette par rapport aux pertes potentielles coté business en raison d’un échec qui n’était pas envisageable avant de contracter cette dette.
Le but de monétiser la dette technique est de limiter le nombre de violations de la qualité structurelle, ou ce qui est plus important, le coût de les réparer, bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.
Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure de calcul de la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont généré la dette technique.
La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite de devoir payer plein d’intérêts.
Alors, profitez de cette période un peu plus calme pour entamer ces travaux de remboursement…
Si vous en connaissez d’autres, n’hésitez pas à les ajouter en commentaires à ce billet et je les intègrerai dans la liste.
Voici une page que je n’avais pas visité depuis plusieurs années et qui continue à répondre à de nombreuses premières questions que vous pourriez avoir si vous cherchez à vous doter d’un logiciel de management de projets et/ou programmes.
Rassemblant les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises, cette étude de CAST sur la qualité logicielle des applications (CRASH), présente l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.
L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.
La sortie de Microsoft Project Server 2013 il y a un peu plus de deux ans permettait pour la première fois un accès optimisé aux données projet depuis des appareils mobiles, facilitant ainsi la communication et la collaboration au sein des équipes.
La possibilité d’utiliser l’étendue des fonctionnalités de Microsoft Project Server en tant que service en ligne depuis le cloud avait elle aussi suscité un grand intérêt car elle permettait de simplifier le déploiement de l’outil dans toute l’entreprise, allégeant ainsi la charge du département IT. Bien que la nouvelle version Microsoft Project 2016 semble moins innovante, les apparences sont trompeuses, comme a pu le constater Campana & Schott au cours de ses nombreux tests. Les fonctionnalités étendues de management des ressources ont notamment fait très bonne impression car elles permettent de coordonner une organisation matricielle nettement plus efficacement qu’auparavant. En fonction de la spécialité de chaque entreprise, la mise à niveau avec la nouvelle version promet non seulement un gain de productivité significatif, mais aussi une gestion multi-projets plus souple, ce qui s’accompagne évidemment d’une plus grande réactivité face à la concurrence.
Les versions actuelles de Microsoft Project Server et Project Online offrent d’ores et déjà un aperçu global de l’évolution des projets en cours, depuis différentes perspectives. Les responsables de ressources et supérieurs hiérarchiques peuvent ainsi voir à tout moment sur quels projets leurs ressources sont affectées. Cependant, dans la pratique, ces affectations sont sujettes à de nombreuses modifications : certains employés peuvent subitement ne plus être disponibles pour raison de maladie ou parce qu’ils sont appelés ailleurs pour une urgence. Par conséquent, les chefs de projet sont amenés à replanifier leurs projets et il devient alors difficile pour les supérieures hiérarchiques d’évaluer rapidement et précisément les répercussions possibles de ces modifications sur les autres projets. L’engagement pris lors de l’affectation initiale est alors rompu. De ce fait, les supérieurs hiérarchiques manquent d’une base de décision valide pour accepter ou refuser les nouvelles demandes de projet affectant les membres de leurs équipes. Cette difficulté est principalement due au fait que la précédente version de Microsoft Project Server ne prévoyait aucun process officiel de validation d’affectation de ressources par les responsables hiérarchiques.
Dans la pratique, on trouve des exemples typiques de ce genre de problématiques aussi bien dans les entreprises de services que dans le génie logiciel et l’ingénierie, secteurs dont la croissance est souvent soudaine et qui implique le déploiement rapide de nombreux sites. Il n’y a, dans les premières années, que peu de projets multi-sites : il est alors facile de garder une vue d’ensemble précise de la répartition des tâches parmi les employés. Mais à mesure du développement de l’entreprise et de l’augmentation du nombre de projets, cet aperçu devient de plus en plus compliqué : le personnel d’un site en particulier sera-t-il sur ou sous-occupé le mois suivant ? Où se trouvent les spécialistes les plus compétents pour le prochain projet ? Dès lors, les demandes urgentes de gros clients ne peuvent plus être traitées dans un délai suffisamment court, un inconvénient de taille dans la relation client. Il est en effet impossible de déterminer directement si la commande concernée pourra être prise en charge dans le délai imparti. Dans de tels cas, il devient finalement indispensable de procéder à une optimisation des outils pour le management des ressources. Cet exemple est typique dans la mesure où, souvent, une infrastructure de gestion de projet qui fonctionne bien à la base ne parvient néanmoins pas à tenir le rythme de croissance de l’entreprise sur le long terme.
Par le passé, les utilisateurs de MS Project Server se servaient souvent de solutions complémentaires spécialisées réconciliant les besoins des projets et les engagements des équipes métiers au sein des organisations matricielles. D’autres ont essayé de modéliser la planification des ressources inter-projets au sein de fichiers Excel complexes. Malheureusement, ces solutions sont rarement pérennes et la double saisie engendrée entraîne d’inévitables incohérences. Résultat : davantage de coûts au lieu de davantage de transparence.
La version Microsoft Project Server 2016 offre de nouvelles perspectives dans la gestion des capacités et des ressources. Les nouvelles fonctionnalités « demande de ressources » et « engagement de ressources » remédient en effet au problème décrit plus haut : l’outil historise l’intégralité des accords et refus délivrés par les responsables hiérarchiques vis-à-vis des demandes d’affectations émanant des chefs de projet. Cela crée ainsi un socle solide sur lequel peut se baser la communication entre toutes les parties prenantes – y compris les responsables hiérarchiques.
Il s’agit là d’une fonctionnalité à forte valeur ajoutée pour le métier, attendue depuis longtemps par de nombreux clients de Campana & Schott. La capacité de décision ainsi acquise au niveau du responsable des ressources peut à elle seule générer un gain de productivité d’environ 10 % dans les entreprises de services. Autre avantage : ces fonctionnalités étendues de Microsoft Project Server 2016 en management de ressources sont directement disponibles, aucune configuration additionnelle n’est nécessaire.
Par ailleurs, la nouvelle version Microsoft Project Server 2016 favorise la prise rapide de décisions par le biais des dites « heat maps » – une fonctionnalité qui impliquait par le passé le recours à un partenaire d’implémentation : des graphiques de couleur permettent maintenant d’identifier d’éventuelles ressources en sur-utilisation ou à contrario en sous-utilisation entre différents projets, et ce même avec un important volume de données et des interdépendances extrêmement complexes.
Les cartes utilisent les couleurs des feux tricolores, avec des seuils à définir librement. Cela permet aux supérieurs hiérarchiques d’agir avec un maximum de flexibilité lors de la planification des interventions et de prévenir ainsi des situations d’impasse au niveau d’un projet ou d’une ressource critique.
La fonctionnalité « Timeline » (frise chronologique) permettait déjà dans Project 2013 de visualiser le déroulement du projet le long d’un axe de temps. La version Microsoft Project 2016 propose à présent dans le client riche l’option de gérer plusieurs axes de temps pour un projet et de les afficher sous forme de barres superposées. Par exemple, la barre supérieure peut représenter le projet dans son ensemble, tandis que celle du dessous décrit plus précisément un lot spécifique du projet. Il est ainsi possible de différencier précisément les phases du projet, sans que les détails ne brouillent la vue d’ensemble du projet.
En outre, l’intégration d’une nouvelle fenêtre de recherche directement dans l’interface du client riche réduit considérablement le temps nécessaire pour trouver des fonctions rarement utilisées.
Avec Project 2016, Microsoft poursuit sa route vers le cloud. Bien que Project Online ne soit disponible que depuis le début de la sortie de Project 2013, la plupart des nouveaux clients britanniques par exemple misent sur la version Online, le plus souvent en association avec Office 365. La France en revanche se montre encore hésitante vis-à-vis des solutions cloud et continue de privilégier la version on premise. Toutefois, l’interaction de Project Online avec d’autres offres de Microsoft dans le cloud devient de plus en plus importante en termes de productivité et d’efficacité – par exemple avec SharePoint Online, Power BI, Skype Entreprise Online, Dynamics CRM Online, ou encore avec la plateforme sociale dédiée aux entreprises Yammer, qui fait partie de Microsoft depuis 2012.
D’un point de vue utilisateur, le grand avantage d’une solution cloud comme Project Online est sans doute sa disponibilité immédiate évitant de longs et fastidieux accords avec le département IT. Comme les versions en ligne sont conçues et mises à disposition des utilisateurs de manière incrémentielle, les cycles d’innovation se raccourcissent. Inutile à présent d’attendre la version suivante : les nouvelles fonctionnalités sont immédiatement disponibles et utilisables. Cela réduit considérablement la charge de travail du département IT puisque le portefeuille d’applications gérées en interne n’augmente pas et les contraintes liées à un changement de version n’ont plus lieu d’être. Pour les PME notamment, qui n’utilisaient jusqu’à présent que le client riche en local, Project Online devient une possibilité simple de passer à Project Server, sans nécessiter d’investissements en nouveau matériel. De même, pour les entreprises utilisant à présent Project Server 2003, 2007 ou 2010 qui envisagent une migration, l’option Online mérite d’être étudiée. Microsoft a d’ores et déjà mis un terme au support global pour les versions 2003 et 2007 et le support devrait s’arrêter d’ici la fin de l’année pour Project Server 2010.
Dans les entreprises dotées d’une organisation matricielle, les avancées significatives en termes de management des ressources de Microsoft Project Server 2016 apportent davantage de transparence entre la planification de projet et la planification hiérarchique. L’historisation des validations concernant les demandes d’affectation de ressources permet une meilleure visibilité et communication entre les différentes parties prenantes. Les outils complémentaires pour la planification des ressources tels que les tableurs Excel deviennent ainsi superflus. Par ailleurs, des rapports standards et des « heat maps » intégrés facilitent l’analyse d’éventuelles sur-affectations ou sous-affectations des ressources entre les différents projets de l’entreprise. Dans l’ensemble, la solution avancée de gestion des ressources proposée par Microsoft Project Server 2016 agit comme un important levier pour l’amélioration de la répartition des activités parmi les acteurs projet et donc pour l’augmentation de la productivité de l’entreprise. En effet, plus la part de chiffre d’affaires générée par ressource est élevée, plus l’impact d’une planification optimisée influe sur le résultat commercial. Néanmoins, il ne faut pas oublier qu’un outil de management, aussi performant soit-il, ne portera aucun fruit s’il n’est pas accompagné de procédures, règles et rôles appropriés afin de l’ancrer dans l’organisation.
Get a free chapter of my first book, Project Management in the Real World, on creating a realistic project budget. It’s actually the first 25 pages of the book, so you get a great glossary of project management terms as well. Get instant access to the document (.pdf)
Sign up for Elizabeth’s free six week, self-paced e-learning course. You’ll learn everything you need to know to take your first steps with using social media tools on your projects. Read more about it.
Get your copy of the Inside PRINCE2 ebook. It’s a great introduction to PRINCE2, but it’s also useful for people who aren’t PRINCE2 Practitioners (or who aren’t aiming to be) because it also covers project tolerances, fixed date projects and other stuff useful for all project managers. Get your free copy (about half-way down the page).
Elizabeth has been reviewing project management books and project management software for over 5 years now, so there is a library of information available for you before you make an investment in reading material or software tools. Check out the index of book reviews and the index of software reviews.
Campana & Schott est un cabinet de conseil international en management de projet et collaboration sociale, spécialisé dans la mise en œuvre de Microsoft Project et Project Server en entreprise.Le monde du travail est en évolution constante. Afin d’assurer leur longévité et de conserver leur compétitivité, les entreprises doivent en permanence faire face à des changements.
Depuis plus de 20 ans, Campana & Schott vous apporte toute son expérience et ses compétences en gestion de projet pour vous accompagner dans ces évolutions et dans la conduite du changement.
Campana & Schott est un partenaire de référence de Microsoft en France, en Europe et aux États-Unis. Cinq compétences sont actuellement reconnues par Microsoft et Campana & Schott est un partenaire Gold de Microsoft.
Depuis de nombreuses années, Campana & Schott s’est également spécialisé dans l’intégration de Project Server avec les systèmes d’information de vos organisations (ERP, LoB …) et dans la fourniture d’extensions apportant de la valeur à votre solution de management de projet Microsoft existante.
Ainsi Campana & Schott propose CS Connect, une interface standardisée, flexible et performante pour la synchronisation bidirectionnelle de différentes sources de données (notamment Project Server avec SAP).
Campana & Schott propose aussi des extensions à Project Server qui permettent :
Enfin, Campana & Schott a publié quatre applications pour Project Online et SharePoint Online. Destinées aux chefs de projets, administrateurs et équipes de projets, elles permettent d’améliorer leur productivité. Téléchargez les applications ou une version d’essai gratuite de 30 jours désormais disponibles sur l’Office Store.
Toutes les applications sont également disponibles pour SharePoint 2013 ou Project Server 2013 On Premise.
L’application CS Milestone Trend Analysis permet l’historisation des données de Microsoft Project Online ou Microsoft Project Server 2013. L d’une « courbe à 45° », contrôlez vos jalons au fil du temps, analysez les tendances, identifiez les dérives et réagissez aussitôt.
Cliquez-ici pour en savoir plus et pour télécharger l’application
CS Multi Project Editor est une extension pour Microsoft Project Online et Microsoft Project Server 2013 permettant l’édition en masse des projets et de leurs champs personnalisés d’entreprise. Editez et sauvegardez plusieurs projets à la fois !
Cliquez-ici pour en savoir plus et pour télécharger l’application
CS Task Board ajoute une liste et un tableau kanban à votre site SharePoint Online ou Project Online. Visualisez vos tâches sous la forme de Post-IT® et actualisez-les par glisser-déposer. Utilisez des options de recherche/filtrage par mots-clés afin de les gérer efficacement.
Cliquez-ici pour en savoir plus et pour télécharger l’application
L’application CS Risk Matrix ajoute une liste et une matrice en couleurs à votre site SharePoint Online ou Project Online qui permet d’éditer vos risques par glisser-déposer. Utilisez le filtrage par mots-clés afin de les gérer efficacement.
Cliquez-ici pour en savoir plus et pour télécharger l’application
Campana & Schott – La collaboration sociale au cœur du management de projet.
Robustness
Key findings:
Le pilotage par l’effort est une fonctionnalité (pour ne pas dire un concept) aussi essentielle dans Microsoft Project que méconnue par bon nombre d’utilisateurs de l’outil de planification.
Dans le cadre de nombreux projets (et pour la majorité des tâches qui les composent), l’estimation de la charge est déterminante et sert ensuite à évaluer les délais des tâches, en fonction des ressources disponibles. Quand un chef de projet demande un conseil avisé à un expert pour l’estimation des tâches d’une tâche, celui-ci répond le plus souvent ainsi : « Il y en a pour x jours de boulot » . Il ne faut surtout pas se tromper: ces jours ne représentent pas un délai mais une charge de travail !
Dès lors, cette estimation peut être intégrée au planning par le chef de projet et en aucun cas, lors de l’affectation des ressources, cette charge ne devra être recalculée par Microsoft Project.
Pour s’en assurer, l’utilisateur doit modifier le type de tâche et choisir « Travail fixe » afin que le travail ne soit pas recalculé par Project. Si le travail est fixe, il est « sanctuarisé » et seul l’utilisateur pourra en modifier la valeur.
Choisir le « Travail fixe » a une autre conséquence : la tâche devient alors automatiquement (et obligatoirement) « pilotée par l’effort ». Cette option de pilotage par l’effort (appelée aussi pilotage par la charge) permet, lorsque le chef de projet effectue des affectations successives de ressources, que la charge soit partagée entre ces ressources. En conséquence, la durée de la tâche est recalculée (selon l’équation éternelle : Travail = Durée x Capacité).
Dans d’autres cas de figure, les affectations de ressources successives ne doivent pas avoir pour conséquence le partage de la charge (et donc la réduction de la durée) mais l’inverse : conserver la même durée et ajouter une charge supplémentaire induite par l’affectation de nouvelles ressources sur la tâche.
Je cite souvent en formation l’exemple d’une tâche qui pourrait s’appeler « Séminaire » : une telle tâche n’est jamais pilotée par la charge. C’est dans ce cas la durée qui est fixée d’emblée (et ne variera pas en fonction du nombre d’utilisateurs). Y affecter des participants permet en quelque sorte de déterminer le coût en jours-hommes du séminaire.
Suite à une question posée par un contact, Vincent Capitaine a réalisé un tableau simple qui récapitule les différences entre les versions « Standard » et « Professional » de Microsoft Project 2013.
Gestion de portefeuille opérationnel et stratégique, ressources d’entreprise mutualisées, reporting d’entreprise (multi-projets, multi-ressources), saisie de l’activité par les ressources, site Web collaboratif SharePoint (partage documentaire, gestion des risques…), partage d’informations en ligne avec l’équipe projet (via le client Web Project Web App…), utilisation de métadonnées de caractérisation des projets pour le reporting, etc.
Permet la synchronisation d’un planning Microsoft Project avec une liste de tâches SharePoint de manière bidirectionnelle, permettant aux parties prenantes du projet de consulter et/ou de mettre à jour le planning directement dans une interface Web.
Lorsque les ressources sont extraites de l’Active Directory et affectées aux tâches, pouvoir en tant que chef de projet de créer une discussion (chat, audio, vidéo), un partage documentaire… avec la ressource
Cette fonction permet d’activer ou inactiver des tâches dans un planning, permettant la réalisation de scénarios, des simulations de type « what-if »).
Un affichage permettant d’affecter les tâches aux ressources via un simple « Glisser-Déplacer » qui offre une vue chronologique sur l’occupation des ressources.
Seule la version Professional est disponible dans le cadre de l’offre Microsoft Office 365. Le nom de cette version est : « Microsoft Project Pro pour Office 365 ».
Depuis de nombreuses années, Campana & Schott s’est également spécialisé dans l’intégration de Project Server avec les systèmes d’information de vos organisations (ERP, LoB…) et dans la fourniture d’extensions apportant de la valeur à votre solution de management de projet Microsoft existante.
Ainsi Campana & Schott propose CS Connect, une interface standardisée, flexible et performante pour la synchronisation bidirectionnelle de différentes sources de données (notamment Project Server avec SAP).
Enfin, Campana & Schott a publié quatre applications pour Project Online et SharePoint Online. Destinées aux chefs de projets, administrateurs et équipes de projets, elles permettent d’améliorer leur productivité. Téléchargez les applications ou une version d’essai gratuite de 30 jours désormais disponibles sur l’Office Store.
Toutes les applications sont également disponibles pour SharePoint 2013 ou Project Server 2013 On Premise.
L’application CS Milestone Trend Analysis permet l’historisation des données de Microsoft Project Online ou Microsoft Project Server 2013. L d’une « courbe à 45° », contrôlez vos jalons au fil du temps, analysez les tendances, identifiez les dérives et réagissez aussitôt.
Cliquez-ici pour en savoir plus et pour télécharger l’application
CS Multi Project Editor est une extension pour Microsoft Project Online et Microsoft Project Server 2013 permettant l’édition en masse des projets et de leurs champs personnalisés d’entreprise. Editez et sauvegardez plusieurs projets à la fois !
Cliquez-ici pour en savoir plus et pour télécharger l’application
CS Task Board ajoute une liste et un tableau kanban à votre site SharePoint Online ou Project Online. Visualisez vos tâches sous la forme de Post-IT® et actualisez-les par glisser-déposer. Utilisez des options de recherche/filtrage par mots-clés afin de les gérer efficacement.
Cliquez-ici pour en savoir plus et pour télécharger l’application
L’application CS Risk Matrix ajoute une liste et une matrice en couleurs à votre site SharePoint Online ou Project Online qui permet d’éditer vos risques par glisser-déposer. Utilisez le filtrage par mots-clés afin de les gérer efficacement.
Cliquez-ici pour en savoir plus et pour télécharger l’application
En résumé, Campana & Schott est une entreprise dynamique et reconnue :
établie depuis 1992 et toujours gérée par les fondateurs-propriétaires ;
La Project Conférence 2014 à Anaheim fut un brillant succès et notre partenaire Campana & Schott a profité de cette conférence pour présenter quatre nouvelle applications disponibles sur l’Office Store de Microsoft pour Project Online et SharePoint Online.
Ces applications sont disponibles pour Project Server 2013 et SharePoint Server 2013 et des versions d’essai gratuites peuvent être téléchargées en ligne.
CS Task BoardAjouter une liste et un tableau KANBAN aux sites SharePoint Online ou Project Online. Elle permet de visualiser les tâches sous la forme de Post-IT® et de les actualiser par glisser-déposer. Les tâches peuvent être gérées, recherchées et filtrées efficacement avec des mots-clés.
CS Milestone Trend AnalysisHistorisation des données de Microsoft Project Online ou Microsoft Project Server 2013. L’application permet la création d’une « courbe à 45° », de contrôler les jalons d’un projet au fil du temps, d’analyser les tendances, d’identifier les dérives et donc, de mieux réagir !
CS Risk MatrixAjouter une liste aux sites SharePoint Online ou Project Online permettant de gérer efficacement les risques. Ceux-ci s’affichent également dans une matrice à trois couleurs et peuvent être mis à jour par un simple glisser-déposer. Les risques peuvent être gérés et filtrés aisément via la définition de mots-clés.
CS Multi Project EditorCette application satisfera tous les utilisateurs et administrateurs de Project Server 2013 et Project Online désireux de gérer en masse les métadonnées des projets !
Pour en savoir davantage, visitez le site Campana & Schott.
http://www.projectmanager.com/4-benefits-of-the-iterative-nature-of-the-scrum-methodology
Nous sommes tout familiers des sorties de logiciel majeures. Prenez votre machine à remonter le temps et pensez à l’environnement Windows. Il y a eu Windows 3.0, Windows 95, Windows 98, Windows 2000, Windows XP, Windows Vista et Windows 8.
Chacune de ces sorties majeures a été conçue avec de nouvelles fonctionnalités et des améliorations technologiques par rapport aux précédentes.
Une sortie de version majeure est la super nouvelle version d’un produit logiciel ou d’une application Web qui contient tout ce que tout le monde a demandé depuis la dernière grande version. C’est la solution à tous les problèmes et c’est la litanie qui est répétée quand on pose la question de pourquoi le logiciel ne fonctionne pas actuellement d’une certaine façon. La réponse est une longue répétition de « dans la prochaine version 9.0…9.0 ….9.0 … ».
Ceci peut être bel et bon, mais il y a des problèmes associés à cette Approche de sortie de version majeure qui essaie de tout mettre dans la prochaine version. Nous discuterons certains de ces défis avec la méthode de Conduite de projet agile, comme le développement Scrum, qui peut rendre ces sorties plus itératives, plus petites et plus fréquentes.
Il y a un certain nombre de défis qui existent avec cette méthode de développement logiciel qui suit le chemin de méthodologies de développement plus rigides comme la méthode dites en Cascade.
Des versions majeures sortent typiquement éloignées l’une de l’autre. Bien sûr, il peut y avoir des versions mineures en chemin (comme 9.1 ou 9.05 selon la taille de la version), mais celles-ci sont d’habitude reléguées aux corrections de bogue et corrections de fonctionnalité existante.
Le contenu vraiment nouveau et passionnant nécessite d’habitude 4 à 6 mois et dans ce monde exigeant de satisfactions instantanées, ceci peut sembler une éternité. De plus, ceci nous mène aux conversations répétées avec des clients et des utilisateurs finaux que ce qu’ils veulent vraiment que le logiciel fasse se trouve à un certain point dans un avenir éloigné.
De surcroît, comme les dates approchent, il y a typiquement un certain type de débordement de périmètre qui a été introduit en chemin et la fonction ne marche pas comme prévue, ce qui repousse la date de livraison encore plus loin.
Des idées feront surface pendant le développement de la version majeure. Elles sont de si excellentes idées et feraient une si grande différence pour l’utilisateur final qu’il serait déraisonnable d’attendre la version majeure suivante qui pourrait être 8 à 12 mois plus tard.
Ces grandes idées forcent leur passage dans un espace qui est déjà encombré de fonctionnalités. De plus, il n’y a d’habitude pas assez de personnes disponibles pour implémenter le premier cercle de fonctionnalités sans parler du périmètre supplémentaire qui a été introduit. Ceci contribue en partie aux raisons des retards potentiels mentionnés ci-dessus.
Maintenant il y a ce poids lourd de la version majeure qui hante couloirs et bureaux. Elle prend sur une vie à part et commence à bousculer les gens quand ses besoins ne sont pas respectés.
Ses besoins se sont étendus pour inclure des tests supplémentaires, davantage de documentation et la conduite de plus de groupes de discussion pour voir si la nouvelle fonctionnalité est facile de comprendre et utiliser. Ceci exige beaucoup de management pour mener cette version monstrueuse à l’achèvement et éviter qu’elle ne nous échappe.
Un changement substantiel à l’UI est typiquement associé à une version majeure. Ceci exige une courbe d’apprentissage de la part de l’utilisateur final comme tout le monde appréhende la nouvelle interface.
Rappelez-vous des changements dans la navigation que Microsoft a pas fait il n’y a pas si longtemps dans la navigation basée sur le Menu que tout le monde connaissait depuis des années vers l’approche de Ruban qui a agrégé des fonctions liées en un même endroit. Nous y sommes habitués maintenant mais cela a pris du temps de s’adapter à la nouvelle façon de faire les choses.
Puisqu’il y a tant de personnes impliquées dans une sortie de version majeure de dimensions Herculéennes, il devient dur d’identifier précisément et de résoudre les problèmes. Les problèmes pourraient apparaître dans une zone qui impacte négativement une autre zone.
Par exemple, une application Web peut prendre excessivement longtemps à se charger. Rien de changé côté code et tout le monde dans les autres services jure que rien n’a changé non plus.
« Attendez, euh…, » dit timidement le service informatique « nous avons vraiment récemment fait un changement mineur dans le réseau qui pourrait limiter le débit ».
Bien sûr, ce dont on pensait que cela n’avait aucun rapport avec la cause du problème finit par être le coupable.
Il y a eu un changement vers des méthodologies de conduite de projet plus agiles ces dernières années. Ceci a ouvert la porte pour des versions logicielles plus itératives et a réduit la durée entre chaque sortie majeure suivante. Voici certains des avantages de la méthodologie Scrum.
Les phases de la méthodologie Scrum se concentrent sur des sorties fréquentes avec moins de fonctionnalités. Initialement, ceci peut donner l’impression d’être négatif. Qui voudrait moins de fonctionnalité ? Eh bien, plutôt qu’attendre 4 à 6 mois pour avoir toute la fonctionnalité, la méthodologie Scrum permet aux versions d’être accélérées. Dans la plupart des cas, une version peut être sortie toutes les 4 à 6 semaines! Le cycle de développement est appelé un Sprint, qui en dit long sur la nature abrégée de la méthodologie Scrum.
La nature itérative de la méthodologie Scrum se prête à une concentration au laser sur quelques fonctionnalités, la facilité d’utilisation et la valeur pour l’utilisateur final. Chaque version doit donner de la valeur à l’utilisateur final. À un certain niveau, cela pourrait être vu comme une approche par phase de versions majeures. Plutôt que d’attendre que tout soit fait en même temps, les fonctionnalités sortent comme elles sont produites et mises en ligne.
Des méthodologies de conduite de projet agiles comme la méthodologie Scrum embrassent le changement. La méthode en cascade qui est si commune pour des versions majeures est typiquement résistante au changement. Il y a des formulaires, des réunions, des approbations et autres contrôles mis en place dans le but d’empêcher le changement avec les méthodologies conventionnelles. La nature itérative de la méthodologie Scrum cherche un retour d’information continu et ajuste ensuite le plan et les jeux de fonctionnalités en conséquence.
Plus de demandes se déplacent vers le Modèle du Logiciel comme un Service (SaaS). Ceci est quand l’application en ligne est vivante, une entité qui respire et à laquelle les gens adhèrent selon leurs besoins. Une partie des attentes autour du modèle SaaS est qu’il y aura des changements et des améliorations continus au logiciel. Ceci encourage des abonnés à la demande à continuer à renouveler mois après mois. La méthodologie Scrum facilite ceci.
Le temps où attendre 4-6 mois entre des versions majeures est révolu. Les gens n’ont plus ce type de patience et il y a des alternatives pour ne pas avoir à attendre si longtemps. Même si vous n’adoptez pas la méthodologie Scrum en entier, il y a de certains principes que vous pouvez utiliser qui permettront à vos projets d’avancer plus rapidement.
ProjectManager.com croit en la livraison fréquente de super fonctionnalités à ses utilisateurs finaux.
Vous souhaitez en savoir plus sur la solution PPM et la prendre en main avant de vous décider ? C’est bien naturel !
Pour cela, Microsoft et Campana & Schott mettent à votre disposition une plateforme de test afin d’évaluer l’ensemble des fonctionnalités de Project Online. Et bonne nouvelle : c’est entièrement GRATUIT !
Votre plateforme d’évaluation de Project Online sera disponible à hauteur de 5 utilisateurs pendant un mois. Grâce à deux sessions de présentation en ligne, vous apprendrez comment accéder à un environnement entièrement fonctionnel et comment évaluer les fonctionnalités de Project Online, Project Professional inclus. Les experts de Campana & Schott seront à votre disposition par téléphone afin de répondre à toutes vos questions.
Pour un essai, envoyez un email à ppm@campana-schott.com
Jean-Yves Moine, Consultant avec plus de 15 ans d’expérience, auteur de 5 ouvrages sur la gestion de projet dont 4 chez AFNOR éditions, dont j’ai présenté le dernier livre « Le grand livre de la gestion de projet » récemment, est le créateur de la méthode de structuration de projet « WBS 3D », également évoquée sur ce blog précédemment. Il a effectué plusieurs conférences sur le WBS 3D, dont deux au PMI.
Jean-Yves Moine a participé, en tant de référent technique, à la définition du logiciel Cubix360. Ce logiciel est l’aboutissement d’un long cheminement de pensée et de nombreuses années d’expériences sur des grands projets industriels en France et à l’international. A ce titre, il nous présente aujourd’hui Cubix360.
Cubix360 permet de créer des plannings MS PROJECT ou PRIMAVERA P6 bien et rapidement. Le planning est créé au sein de Cubix360 puis il est exporté vers les logiciels de planification, ce qui génère le planning.
A savoir les Activités (ABS, Activity Breakdown Structure : Activités ou actions au sens processus), les Produits (PBS, Product Breakdown Structure : équipements, ouvrages de génie civil, modules informatiques, etc.) et les Zones (ZBS, Zone Breakdown Structure : Zones géographiques, releases d’un logiciel, zones fonctionnelles, etc.), conformément à la méthode WBS 3D.
Les plannings créés avec Cubix360 sont d’excellente qualité, très bien structurés et en plus ils sont multidimensionnels, c’est à dire que les structures élémentaires qui composent le WBS sont liées.
Ceci est dû d’une part à l’import des structures élémentaires dans Cubix360 évitant ainsi la saisie de données, ainsi qu’à la factorisation des Produits au sein des matrices de Cubix360. L’information est en effet saisie au sein de matrices, puis elle est démultipliée ce qui génère le planning.
Cubix360 propose une approche nouvelle dans le monde de la planification, même si en réalité la méthode WBS 3D est utilisée depuis déjà de nombreuses années tout à fait naturellement chez des grands comptes sans qu’elle soit nommée et rationalisée.
Cubix360 s’applique aussi bien sur des petits que sur de grands projets, mais plus le projet est important et complexe, plus l’utilisation de Cubix360 apporte de la valeur.
Ci-dessous une présentation vidéo du logiciel.
Suivez la formation gratuite: Cubix360 propose une formation gratuite à la planification de projet par Jean-Yves Moine
Get the full report for free online.
DantotsuPM.com 