Tag Archives: software

selon le CRASH report: nous sommes sur la bonne voie dans nos projets informatiques et technologiques

17 Mar

Cette  année encore, CAST software a analysé plus de 1850 applications pour mieux comprendre comment les pratiques de développement et de livraison impactent l’IT ainsi que la performance de l’organisation.

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 !

Obtenez votre copie gratuite du rapport (en langue anglaise)

Voici quelques découvertes :

  • Le secteur public est le plus sûr
  • La taille des équipes de développement fait une différence
  • Le type de « sourcing » a peu d’influence sur la santé globale des logiciels
  • Les méthodes de développement hybrides ont de bons résultats

Vous pouvez télécharger le rapport complet ici.

Enregistrer

Enregistrer

Enregistrer

21 March – Webinar – Introduction to #SAFe 4.0

15 Mar

click on the image to register for this free webinar

SAFe®(Scaled Agile Framework) is the largest growing Agile scaling framework and has been adopted by over 65 of the fortune 500 companies. Temenos+Agility is one of the few worldwide SAFe® SPCT Gold Partners of Scaled Agile with over 100 years of combined experience in deep Enterprise, Cultural and Leadership Agility transformations.

This webinar session is an Introduction to SAFe® where you will get an insight by understanding Lean-Agile Methodologies and systems development for a better enterprise culture.

This Webinar will also educate you on the overall Scaled Agile Framework, the purpose and the function of the people involved in the framework and the Quality measures for implementing it without any obstacles.

The following points will also be covered:

  • Building incrementally to accelerate value delivery.
  • Guidance for work at the Portfolio level, Value Stream, Program and Team levels.
  • In Building the Backlog for a better growth.
  • A path of Relentless Improvement for sustainability.
  • And solutions for Value Delivery in determining success patterns.

Enregistrer

14 Février – Lausanne – La protection des données personnelles : Un défi pour le chef de projet ?

31 Jan

Les enjeux sont importants car corriger a posteriori un système qui serait non conforme est une véritable gageure !

Cyber criminalitéDisons-le clairement, traiter les données personnelles de manière conforme dans tout nouveau projet peut se révéler être un défi pour le chef de projet. Un défi, car les obligations légales existent en ce domaine, mais les formations intégrant cet aspect sont encore rares.

Hors, les corrections après coup sont très coûteux en temps, en énergie et en argent.

Isabelle Dubois

Isabelle Dubois

Au cours de cette soirée animée par Isabelle Dubois, AD HOC RESOLUTION, vous pourrez vous sensibiliser à cette matière et :

  • Prendre conscience de ce que sont les données personnelles et les données sensibles
  • Découvrir les règles et principes applicables au traitement de ces données
  • Aborder les sujets qui vous (pré)occupent actuellement, tel que l’externalisation des données

La conférence sera suivie par un apéritif dînatoire.

Détails et inscriptions

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Enregistrer

Enregistrer

Une journée dans la peau d’un chef de projet – édition 2017 de Campana & Schott

31 Jan

Les outils évoluent, le chef de projet apprend à en tirer tous les bénéfices !

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é.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

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.

une-journee-pm-csTélécharger le livre blanc (3.3 M)

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

connaissez-vous les 12 principes Agile qui accompagnent les 4 composantes majeures du « Agile Manifesto » ?

10 Jan

Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste Agile, les connaissez-vous ?

Examining the Twelve Principles of Agile par The Clever PM

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…

1. Notre priorité la plus haute est de satisfaire le client par la livraison rapide et continue de logiciel de valeur.

bonhom-serviceCeci 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.

2. Accueillez avec bienveillance les demandes d changement, même tard dans le développement. Les processus agiles exploitent le changement pour donner un avantage compétitif du client.

changementsLa 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.

Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin

Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin

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.

3. Livrez souvent (entre deux semaines et deux mois) du logiciel qui fonctionne avec une préférence pour les fréquences les plus rapides.

scrumIl 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.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

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.

4. Les gens du métier et les développeurs doivent travailler ensemble quotidiennement pendant tout le projet.

collaborateLa 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.

5. Construisez les projets autour de personnes motivées. Donnez-leur l’environnement et le support dont elles ont besoin et faites leur confiance pour faire le travail.

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.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

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.

6. La méthode la plus efficace et effective de transmettre des informations dans une équipe de développement est la conversation en face à face.

Business DiscussionLa 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.

7. Le logiciel qui marche est la principale mesure de progrès.

avis perso KPIsParticuliè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.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

8. Les processus agiles font la promotion du développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir indéfiniment tenir une allure constante.

Voir les billets sur l'initiative ecoPMI

Voir les billets sur l’initiative #ecoPMI

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.

9. L’attention continue à l’excellence technique et à la bonne conception améliore l’agilité.

good and badDes é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.

10. Simplicité, l’art de maximiser la quantité de travail non fait, est essentielle.

construction progressive. Chaque brique apporte de la valeur.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

11. Les meilleures architectures, besoins et conceptions naissent d’équipes auto organisées.

teamingLe 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.

12. À intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis règle et ajuste son comportement en conséquence.

Get the book on Amazon

Get the book on Amazon

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.

Enregistrer

Enregistrer

bonne résolution de fin d’année: remboursez votre « dette technique » !

13 Déc

Nous sommes devenus une société de débiteurs, dans nos vies comme dans nos projets informatiques !

Technical Debt : No penalty for early payment posté Par Jon sur le blog de Cast Software

empty pocketsNous 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. »

bonhom-boulet

Le boulet de la dette technique peut vous empêcher d’avancer.

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 ?

Combien est assez ?

bonhom-calculator-business

Calculez le coût de votre dette technique

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.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Un plan d’action pour la Dette Technique

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.

Bill Curtis

Bill Curtis

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.

technical-debt-software-qualityUne 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.

bonhom-travaux-roadworks

Le remboursement de la dette technique demande parfois des travaux importants

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.

De plus, il n’y a aucune pénalité à rembourser en avance… en fait, cela apporte une récompense significative grâce à un logiciel de meilleure qualité.

Alors, profitez de cette période un peu plus calme pour entamer ces travaux de remboursement…

Enregistrer

Enregistrer

Enregistrer

Enregistrer

15 December – Webinar (#PMI®) – What does the IT employment market look like for the year ahead?

9 Déc

Business priorities are changing, what does this means for accessing talent in a landscape of skills shortages?

Antonio Nieto-Rodriguez, Chairmain of the Project Management Institute


Antonio Nieto-Rodriguez, Chairmain of the Project Management Institute

Following the recent launch for their Hays UK Salary and Recruiting Trends 2017 guide where we delve deeper into what this means for IT.

James Milligan, Hays IT Director, will be joined by Professor Antonio Nieto-Rodriguez, Chairman of PMI as well as Kevin Troy, Director of Insights from Stack Overflow and who will be discussing business and digital transformation developments.

Register

PMI is a registered mark of Project Management Institute, Inc.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Enregistrer

Enregistrer

3 Blogs MS Project à suivre !

2 Nov

Il existe au moins 3 blogs intéressants pour les utilisateurs de MS Project: « Voix des Utilisateurs », Annonces et Support.

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Il sont tous les 3 en langue anglaise.

  1. Microsoft Project’s UserVoice site: Le site pour soumettre toutes vos idées et suggestions pour Project Desktop, Project Server, et Project Online.
  2. Announcement Blog: Toutes les annonces autour des produits Microsoft liés au management de projet. Conférences, nouvelles fonctionnalités, articles…
  3. Support Blog: Comme le nom l’indique, l’endroit à visiter pour le support, les mises à jour des logiciels, les astuces.

Si vous en connaissez d’autres, n’hésitez pas à les ajouter en commentaires à ce billet et je les intègrerai dans la liste.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Enregistrer

Enregistrer

les articles les plus lus sur DantotsuPM en Avril 2016

8 Août

Une très grande variété dans les billets que les lecteurs ont préférés en Avril 2016: Entreprise libérée, certifications, logiciels de management de projet, techniques de résolution de conflit, mise en œuvre des nouvelles aptitudes post formation…Vincent Iacolare

l’Entreprise libérée, pourquoi ça (ne) marche (pas) ? par Vincent Iacolare

L’entreprise libérée fait parler d’elle ! En bien ou en mal, succès ou échec, il est important de s’y intéresser comme piste de modernité et de durabilité.

voici 10 mythes du management de projet qu’il reste intéressant de garder à l’esprit

Si je jette un coup d’œil en arrière vers le début des années 1990, beaucoup de collègues avaient l’habitude de dire que le management de projet est le meilleur secret caché du business.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Wikipedia – Project Management Software

170 logiciels en management de projet répertoriés, comparés et informations régulièrement actualisées !

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

des performances hors normes pour le Forum National 2016 de PMI France !

PMI France Forum 2016 - AgendaLe Forum National 2016 de PMI France sur le thème « L’univers du sport, source d’inspiration et de performance de nos Projet» a rencontré un franc succès.

Questions fréquemment posées lors d’entretiens par téléphone

Il est indéniable que la plupart d’entre nous ne se préparent pas du tout pour un entretien d’embauche au téléphone. Le plus souvent, ces entretiens sont inattendus et le demandeur d’emploi peut être pris par surprise lors d’un soudain appel téléphonique.

Marc Burlereaux

Marc Burlereaux

Pourquoi je vais passer la certification PMI-PBA® ? Par Marc Burlereaux

Pourquoi le responsable de programme, chef de projet que je suis va passer une certification sur l’Analyse Métier et en l’occurrence PMI-PBA® : Professional in Business Analysis de PMI (Project Management Institute) ?

Le top 10 des certifications en management de projet: Pas de grosse surprise mais certaines connaissent une forte croissance

Sur les 10 dernières années, aucune certification n’a autant raflé les premières places que celles en management de projet.

comment faire en sorte que les équipes appliquent la formation dans leur travail ?

Comment transformer l’espoir en réalité ?

comment appréhender la culture d’une entreprise ?

Pour comprendre la culture de votre organisation, ce qui vous aidera à mieux intégrer l’organisation et à y réussir dans votre rôle, répondez aux questions suivantes.

Comment résoudre les conflits entre les membres de l’équipe ?

Envisagez les 10 étapes suivantes pour résoudre un conflit entre deux ou davantage membres de l’équipe.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

June 9 – New York – Software Risk Summit

25 Mai
details and registration

details and registration

On June 9, at 5PM, join IT executives and thought-leaders for an exclusive forum on strengthening the resiliency and security of business-critical applications. Leaders from the Software Engineering Institute (SEI), The Boston Consulting Group, BNY Mellon and CAST will discuss best practices to help Fortune 500 companies prevent software outages and data breaches.

More than ever, the complexity of systems, layered with technical risks, exposes companies to heightened business risk from disruptive and damaging outages and events. The 2016 Software Risk Summit provides pragmatic strategies to cost-effectively identify and prevent these structural software risks.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Get the book on Amazon

Get the book on Amazon

Join Rana Foroohar as she examines how software and IT risk has become a top issue in the boardroom. From off-the-record anecdotes from leading CEOs and public figures, to the balance of power between corporations and government entities, Mrs. Foroohar will ask the question: whose responsibility is software risk management?

Mrs. Foroohar is an assistant managing editor at Time and the magazine’s economics columnist. She also appears regularly on CNN, NPR and MSNBC as global economic analyst, covering the intersection of economics, business, politics and foreign affairs for both domestic and international operations. She is the author of Makers and Takers: The Rise of Finance and the Fall of American Business.

%d blogueurs aiment cette page :