Tag Archives: contrat

December 16 – Webinar – what you can learn and apply from contract management methodology in project management

8 Dec

A Comparison and Contrast Between Project Management and Contract Management Methodologies, Processes and Roles

contractThis webinar focuses on what you can learn from contract management (CM) methodology and how it can be applied to your Project Management (PM) role and organization.

Participants will learn basic contract management methodology, key processes and tools used in contract management, the key CM roles and responsibilities, and the relationship and interface between the Contract Manager and the Project Manager.

We’ll discuss which CM practices and key processes we can apply to our PM roles, organizations, and projects and how we can work more effectively with our CM counterparts.

Register for this webinar

Quels sont typiquement les sortes de contrats que vous pourriez offrir ou manager sur vos projets ?

27 Nov

1. Prix Fixe : « au forfait »

2. Couverture des Coûts (aussi connu comme « Coûts+ ») : « en régie avec marge garantie »

  • couts vs processusCoûts + honoraires fixes basés sur un % des coûts avec ou sans prime de motivation
  • Coûts + prime de motivation prédéterminée et acceptée à l’avance
  • Coûts + bonus basé sur des critères de performance subjectifs définis à l’avance

3. Temps et Matériels: « pièces et main d’œuvre »

  • Assez proche des coûts+ mais sans limites prédéfinies

Des questions complémentaires pourraient porter sur vos propres expériences avec chaque type de contrat et lesquels vous considérez les meilleurs selon les circonstances.

Partenaire de DantotsuPM, LE blog du management de projet

Partenaire de DantotsuPM, LE blog du management de projet

N’oubliez pas que un projet c’est aussi …. un contrat

sign offEt, par là même, un engagement formel de réaliser une prestation ou produit dans un certain cadre juridique, économique, commercial, technique etc.

L’ensemble des contraintes et acteurs autour du contrat va au-delà du giron habituel du chef de projet et de son équipe pour le mettre en relation avec des interfaces, obligations, risques et opportunités spécifiques.

Le contrat est le lien principal avec le client, « stakeholder » majeur pour le projet.

La gestion contractuelle s’inscrit donc dans toutes les phases d’exécution des projet.

contactez-nous pour publier une annonce

contactez-nous pour publier une annonce

l’acte de la signature manuelle reste important sur les projets !

22 Apr

importance des signatures formelles sur les projets

En lisant l’article de Tim In gram-Smith sur PMHUT, j’ai essayé de comparer son vécu avec ses clients externes à mon expérience ur des projets informatiques internes à l’entreprise.

En fait, je dois reconnaître que notre position de collègues entre informaticiens et représentants métiers/business en lieu et place d’une relation client-fournisseur entre deux entreprises change quelque peu la donne mais pas autant que l’on pourrait le penser de prime abord.

En fait, les projets les plus réussis sur lesquels j’ai travaillé avaient des objectifs très clairs, documentés par écrit et un engagement fort du management.

sign offCe fut par exemple le cas lors de l’implémentation d’un progiciel de gestion intégré (Enterprise Resource Planning – ERP) au niveau mondial en 18 mois dans une grande multinationale. Le directeur du programme (dont je dirigeais le PMO) s’est assuré de cette clarté d’objectifs en les documentant et les faisant signer par le comité exécutif du programme et par son sponsor, le directeur financier de l’entreprise.

Cette initialisation du programme fut critique à notre réussite: Elle nous a donné un périmètre clair, des objectifs agréés et mesurables, des moyens définis et approuvés tant pour les ressources internes qu’externes, et des engagements forts de support au changement du top management.

Ce programme de déploiement d’ERP comportait également un large volet optimisation et unification des processus et réorganisations des fonctions centrales, régionales et pays de la finance. Tous les processus financiers redéfinis par l’équipe projet furent signés manuellement par les responsables métiers de l’entreprise (contrôleurs financiers des pays, des régions et centraux; responsables de la comptabilité, de la facturation, des achats…).

Une signature manuelle reflète à mon avis un engagement bien plus fort qu’un courrier électronique d’approbation.

Businesswoman Reading a WhitepaperPersonnellement, avant de signer manuellement un document, je le lis de manière très attentive. Il arrive même souvent que je demande une vérification à un expert du domaine en question de mon équipe pour les aspects techniques ou business. Mon sentiment reste qu’une signature manuelle a plus de valeur qu’une approbation électronique. Je réalise qu’il s’agit très certainement d’une perception erronée puisque de nos jours de simples SMS peuvent être pris en compte devant un tribunal, mais je ne suis certainement pas le seul à être victime de cette perception. Et, la perception EST la réalité à laquelle le chef de projet doit souvent faire face. Cela changera-t-il avec les générations Y ou millénium nées avec Internet et les communications mobiles ?

Comme Tim le mentionne dans son article, les tentations sont nombreuses de démarrer sans signatures formelles.

Nous les expérimentons également sur les projets internes, notamment l’excuse des délais imposés, la pression du management et des collègues, et la peur de laisser des employés inoccupés:

1. les délais imposés sont toujours de mauvaises raisons !

deadline“Toute proposition de solution qui ne peut être prête pour le 1er janvier ne nous intéresse pas!”. J’ai été témoin, et même partie prenante je le reconnais maintenant, de nombreuses décisions de choix de projets ou de solutions techniques basées sur des critères de disponibilité prévisionnelle. Certains composants auraient mieux répondu aux besoins business mais semblaient prendre trop de temps. En informatique, un exemple typique est d’essayer à tout prix de réutiliser une application développée dans un service pour un but précis dans d’autres circonstances et pour d’autres objectifs. “Cette application marche bien en Europe, il n’y a pas de raison pour qu’elle ne marche pas en Asie où nous commercialisation les mêmes produits…”. En effet, cela paraît logique et séduisant: moins de développement et de tests, disponibilité des compétences, rapidité d’obtention de la solution…

Hélas, le temps d’adaptation de la solution au nouveau contexte est trop souvent sous estimé et, de plus, l’adéquation de la solution aux besoins de ses futurs utilisateurs largement surestimée avec une prise en compte limitée des contextes, marchés, et cultures différentes. Il en résulte souvent une insatisfaction des nouveaux utilisateurs, ou des délais de mise en service proches au final des autres solutions qui auraient pu être choisies sans ce focus initial sur les délais.

2. la pression du management et des collègues même bien intentionnée est souvent mauvaise conseillère.

douleurLà aussi, même si ces pressions partent de convictions sincères des personnes de supporter la “bonne solution”, elles sont souvent le résultat de vues partielles de la situation ou des objectifs complets du projet.

Elles sont aussi teintées de considérations plus terre à terre de disponibilité des compétences requises pour chaque solution, de luttes de pouvoir interne, de désir de développement de nouvelles compétences dans son département, d’affectation des ressources au niveau global du portefeuille de projets ou de l’entreprise.

On ne peut les ignorer, mais elles ne doivent pas obscurcir notre vision et nous éloigner des critères agréés de choix de la meilleure solution pour votre projet.

3. la volonté d’utiliser à tout prix les ressources disponibles.
Image courtesy of suphakit73 / FreeDigitalPhotos.net

Image courtesy of suphakit73 / FreeDigitalPhotos.net

Autre élément que Tim mentionne dans son article et qui est très important: Le sentiment de devoir à tout prix utiliser les ressources disponibles et non affectées qui est très fort et assez légitime du point de vue du management de l’entreprise.

Mais, du point de vue du projet:

  • Ces ressources ont-elles les compétences requises?
  • Sinon, combien de temps faudra-t-il passer à les former et cela est-il même faisable?
  • Si elles sont disponibles et ont les compétences, est-ce une raison suffisante pour démarrer sans approbation formelle du projet?
SMPP

Partenaire de DantotsuPM

Mon expérience est mitigée.

En fait, si une confiance réciproque et forte existe entre business et informatique, on peut démarrer des projets de tailles réduites, des prototypages, ou du développement incrémental en boucle rapide sans signature formelle.

Mais, sur de gros projets informatiques, cela vaut le coup de sécuriser les approbations de toutes les parties avant de démarrer sous peine de devoir défaire puis refaire (si l’on en a encore les moyens) ce qui aurait été produit avec un manque d’alignement sur les objectifs.

Comme le disait l’un des consultants senior avec lequel j’ai eu la chance de travailler :

“Si vous ne prenez pas le temps maintenant de bien faire les choses,

dites moi quand vous prendrez le temps de les refaire !

Car, n’ayez aucun doute, il vous faudra les refaire.”

20 Mars – Paris – Atelier « Enjeux et défis d’une bonne sous-traitance des projets »

9 Mar

Enjeux et défis d’une bonne sous-traitance des projets

PMGS est partenaire de DantotsuPM depuis sa création

PMGS est partenaire de DantotsuPM depuis sa création

Objectifs de cet atelier :

  • Pourquoi un nouveau référentiel ? Comment l’utiliser ?
  • Comment structurer ses relations durablement avec ses sous-traitants et mettre en place une gouvernance interne de la sous-traitance dans ce but ?
  • Aborder les zones d’ombres de la sous-traitance : RH, partenariat, réversibilité …
  • Retour d’expérience pratique : exemples d’utilisation dont une expérience dans une grande entreprise

 A qui est destiné cet atelier ?

  • Les Directeurs informatiques
  • Les personnes gérant des relations permanentes avec des prestataires
  • Les responsables en charge du pilotage de la sous-traitance au long terme

Ce sera également l’opportunité d’échanger avec les autres participants et notre intervenant.

Un cocktail vous sera proposé à partir de 19h30 !

Attention, il n’y a que 15 places pour cet événement, contactez rapidement Aurélie Pouliquen chez PMGS pour réserver la vôtre !

Register Now!

28 Mai – Toulouse – Les relations contractuelles au cours de la vie du projet

21 May

PMI FS Midi PyrénéesPMI du Chapitre France-sud propose une session sur « Les relations contractuelles au cours de la vie du projet »  co-animée par Christine Espinosa-Racaud et François Picaut chez Planitec, à Toulouse, le mardi 28 mai 2013 de 19h15 à 21h.

Ouvert à tous (avec priorité aux membres ) sur inscription obligatoire et dans la limite des places disponibles.

Merci de vous inscrire en remplissant directement le formulaire d’inscription du mardi 28

Les relations contractuelles au cours de la vie du projet :

contractUn projet c’est aussi …. un contrat
et ainsi un engagement formel de réaliser une prestation ou produit dans un certain cadre juridique, économique, commercial, technique etc.

L’ensemble de contraintes et d’acteurs autour du contrat va au-delà du giron habituel du chef de projet et de son équipe pour le mettre en relation avec des interfaces et des obligations, des risques et des opportunités spécifiques.

Le contrat est le lien principal avec le client, « stakeholder » majeur pour le projet.

La gestion contractuelle des projets s’inscrit donc dans les différentes phases d’exécution :

  • Lesquelles ?
  • Comment ?
  • Quel est le rôle et l’interaction avec le gestionnaire de contrats ?
  • Quels outils de travail que l’on peut mettre en œuvre pour la gestion du contrat ?

Telles sont les questions autour desquelles nous vous proposons de partager et de débattre.

Christine Espinosa-Racaud, actuellement responsable des contrats de partenariat stratégique au sein de Cassidian Test & Services, Christine a 10 ans d’expérience dans la vente de moyens industriels et la négociation de contrats dans le secteur aéronautique civil et militaire. Certifiée PMP depuis 2 ans, elle travaille en étroite collaboration avec les équipes projet de Test & Services.

François Picaut est actuellement responsable de l’équipe PMO pour la Business Line Navigation de Thales Alenia Space, qui est notamment en charge de la réalisation du programme Galileo. Il a plus de 25 ans d’expérience en management de grands projets industriels dans le secteur aérospatial. François travaille également comme consultant et formateur en gestion de projets et préparation aux certifications PMI. Certifié PMP depuis 10 ans, il est responsable des contacts académiques au sein de la Branche Midi-Pyrénées du Chapitre France-Sud du Project Management Institute.

24 Mai – Blagnac – Les relations contractuelles au cours de la vie du projet

17 May

PMI FS Midi PyrénéesPMI du Chapitre France-sud propose une session sur « Les relations contractuelles au cours de la vie du projet »  co-animée par Christine Espinosa-Racaud et François Picaut à Blagnac le vendredi 24 mai 2013 de 12h15 à 14h

Ouvert à tous (avec priorité aux membres ) sur inscription obligatoire et dans la limite des places disponibles.

Merci de vous inscrire en remplissant directement le formulaire d’inscription du vendredi 24

Les relations contractuelles au cours de la vie du projet :

contractUn projet c’est aussi …. un contrat
et ainsi un engagement formel de réaliser une prestation ou produit dans un certain cadre juridique, économique, commercial, technique etc.

L’ensemble de contraintes et d’acteurs autour du contrat va au-delà du giron habituel du chef de projet et de son équipe pour le mettre en relation avec des interfaces et des obligations, des risques et des opportunités spécifiques.

Le contrat est le lien principal avec le client, « stakeholder » majeur pour le projet.

La gestion contractuelle des projets s’inscrit donc dans les différentes phases d’exécution :

  • Lesquelles ?
  • Comment ?
  • Quel est le rôle et l’interaction avec le gestionnaire de contrats ?
  • Quels outils de travail que l’on peut mettre en œuvre pour la gestion du contrat ?

Telles sont les questions autour desquelles nous vous proposons de partager et de débattre.

Christine Espinosa-Racaud, actuellement responsable des contrats de partenariat stratégique au sein de Cassidian Test & Services, Christine a 10 ans d’expérience dans la vente de moyens industriels et la négociation de contrats dans le secteur aéronautique civil et militaire. Certifiée PMP depuis 2 ans, elle travaille en étroite collaboration avec les équipes projet de Test & Services.

François Picaut est actuellement responsable de l’équipe PMO pour la Business Line Navigation de Thales Alenia Space, qui est notamment en charge de la réalisation du programme Galileo. Il a plus de 25 ans d’expérience en management de grands projets industriels dans le secteur aérospatial. François travaille également comme consultant et formateur en gestion de projets et préparation aux certifications PMI. Certifié PMP depuis 10 ans, il est responsable des contacts académiques au sein de la Branche Midi-Pyrénées du Chapitre France-Sud du Project Management Institute.

faire passer le contrat du statut d’ « arme » à celui de « manuel utilisateur » par Tiffany Kemp

14 May

Pourquoi les chefs de projets doivent-ils comprendre les contrats ?

Tiffany KempArticle originalement publié sous le tite « Why Project Managers Need to Understand Contracts » sur PM Today.

Tiffany Kemp est l’auteure de Deal Makers – how intelligent use of contracts can help you sell more and deliver better. Fondatrice et directrice exécutive chez Devant.co.uk, elle a lancé le site web FreeContractAdvice.com  sur lequel elle dispense gratuitement des conseils et partage son expérience sur comment bien préparer et rédiger un contrat.

Dans cet article, le focus est placé sur les chefs de projets et les contrats.

Man pulling out his gunLa vue traditionnelle du contrat chez les chefs de projet peut être brièvement récapitulée par : « Si vous devez sortir le contrat du tiroir, c’est que le projet va vraiment mal. »

Cette perspective associe les contrats à l’échec, aux conflits, à la fin d’une relation commerciale et au début d’un coûteux litige. Elle incarne l’approche du  » contrat comme une arme » où il est utilisé soit pour taper sur l’autre partie, soit défendre votre propre camp, en cas de problèmes. En partant de là, les chefs de projet n’ont pas plus besoin de comprendre des contrats que de comprendre comment survivre dans un monde post-apocalyptique. Parce que, franchement, à l’instant où le contrat sort du tiroir, c’est déjà fini de toute façon.

Mais il y a une meilleure façon d’utiliser nos contrats, pour qu’ils ajoutent la valeur à nos relations commerciales plutôt que de seulement occuper de l’espace dans un meuble d’archivage.

Le « manuel de l’utilisateur pour votre relation commerciale »

Imaginez créer un plan de projet complet et incluant votre diagramme de Gantt, la structure de gouvernance du projet et ses jalons de livraison et ensuite le mettre de côté dans une armoire, pour ne jamais être le regarder de nouveau. Vous vous frayez un chemin dans le projet, espérant faire les bonnes choses aux bons moments, avec le bon standard, en sachant que vous n’aurez pas l’opportunité de regarder le plan de projet de nouveau à moins que vous ne soyez partis si spectaculairement hors-piste que le client ait convoqué ses avocats.

Ce n’est pas une image très confortable, n’est-ce pas ?

Et pourtant, lorsqu’il s’agit du contrat par rapport auquel nous supposons que votre plan de projet va délivrer, c’est exactement ce que nous faisons. Nous dépensons des semaines ou des mois à négocier chaque détail du contrat et ensuite, une fois qu’il est signé, il est mis sous une cloche en verre sur laquelle est inscrit : « En cas d’urgence, briser la vitre ».

Le contrat devrait fournir le cadre pour le développement et la livraison de votre plan de projet. Le contrat devrait exposer clairement :

tiffany kemp - triangle

Si nous regardons chacun de ces trois triangles tout à tour, vous verrez que l’essentiel des contrats commerciaux vous est beaucoup moins étranger que vous pourriez le penser.

 « qui fait quoi, quand ? »

Ce premier triangle nous dit ce que nous devrions livrer et ce dont nous avons besoin du client pour le faire avec succès. Ceci nous donne la matière première pour le diagramme de Gantt, l’échéancier de livraison et les dépendances sur le client qui sont si essentielles pour notre planification de projet.

Close-up of magnifying glass focusing on two peopleC’est aussi le domaine où les problèmes ont le plus de probabilité de surgir au cours du projet. Les désaccords sur le contenu (la portée/le périmètre) sont une source majeure de conflits commerciaux et une zone de stress significatif pour beaucoup de chefs de projet. Pourquoi ? Parce que nous avons une vue fondamentalement différente du contenu selon que nous soyons côté client ou côté vendeur. Les clients ont tendance à voir tous les changements de périmètre comme ‘des clarifications’, tandis que les vendeurs ont tendance à les voir comme ‘des changements’ et donc facturables.

Dans le contrat BAA T5 sur le nouvel aérogare d’Heathrow, BAA a dès le départ reconnu ce problème et s’y est attaqué d’une façon nouvelle. Plutôt que d’assumer tout resterait statique, ils ont accepté que le changement était inévitable. Ils ont créé une structure qui a assuré aux sous-traitants qu’ils seraient payés pour leur temps et matériels tant pour les ‘changements’ que pour les clarifications’, mais ne feraient du bénéfice que sur les ‘changements’. Bien que ceci signifiait que BAA et le sous-traitant devaient toujours trouver un accord pour dire si quelque chose était un changement ou une clarification, cela réduisait significativement le risque pour le sous-traitant et changeait fondamentalement le ton sur la gestion des changements dans le projet.

En tant que un chef de projet, comprendre a) ce qu’est le contenu et b) comment gérer le changement est clé à votre succès. Avoir ceci clairement documenté dans votre contrat, de façon pratique et réalisable, vous donne confiance pour faire respecter une bonne gestion des changements.

Qu’entends-je par ‘bonne’ gestion des changements ?

Je veux dire être clair, transparent et cohérent pour que votre client comprenne que vous êtes heureux de faire quoi qu’ils demandent – pourvu qu’ils en acceptent le coût, le risque, le contenu et/ou les implications sur les délais. Ceci pourrait signifier devoir  retarder d’autres livrables pour trouver une petite place pour quelques fonctionnalités supplémentaires. Cela pourrait signifier un coût additionnel. Ou cela pourrait simplement rendre le projet dans son ensemble plus risqué, auquel cas vous voudrez que le client accepte tout ou partie de ce risque supplémentaire.

Le modèle T5 était si réussi qu’il a été adopté comme la base de contrat de sous-traitance sur la construction du Parc Olympique. Dans ce contexte, il a aussi livré quelques résultats novateurs en termes de durabilité et l’utilisation de matériels qui n’auraient tout simplement pas été réalisables sous le modèle habituel qui consiste à faire porter tous les risques aux fournisseurs.

‘ Quand le paiement se produit-il ? ‘

achievementEn tant que un chef de projet, vous pourriez ne pas être terriblement concentrés sur le paiement en soi. Mais le passage de vos jalons de livraison sera tout en haut de votre liste de priorités ! Généralement, les deux sont liés et chaque jalon va probablement être associé à un paiement partiel correspondant qui permet le financement du projet au fil de son exécution.

De votre perspective, regardez le contrat pour voir s’il explique clairement comment vous saurez quand un jalon de livraison a été passé.

Les jalons devraient être clairs, sans équivoque et objectivement mesurables. Aussi « le produit a été démontré comme fonctionnant à la satisfaction du client dans des conditions d’essai » n’est-il pas une bonne description de jalon!

Qu’entendons-nous « des conditions d’essai » ? Que devons-nous faire pour que le client soit « satisfait » ?

Soyez impliqués, prenez un rôle actif dans l’examen du contrat et assurez-vous que vous créez  seulement des jalons avec des livrables objectivement prouvables.

Cela vaut aussi la peine de penser aux contretemps. Qu’arrivera-t-il si le client ne réalise pas les tests ? Ou s’ils décident de l’utiliser en production bien qu’ils vous disent qu’il n’est pas « accepté » ? Efforcez-vous de vous assurer que l’on considère votre jalon comme « accepté » sauf si on vous le refuse dans un laps de temps limité après la livraison.

Qu’advient-il si ça tourne mal ?

balance de la justiceDans le troisième triangle, nous expliquons clairement les conséquences de l’échec. Ceci peut être lié à comment nous traiterons un taux d’erreur plus élevé que celui défini pour les tests d’acceptation. Ou bien comment une réclamation sous garantie sera traitée, ou les circonstances dans lesquelles le client aura le droit de rejeter les livrables. Ou encore, cela pourrait toucher à comment sont mesurés les niveaux de service et comment les pénalités seront calculées si vous manquez vos objectifs.

Si les choses tournent vraiment mal, il pourrait aborder comment votre organisation limite son exposition commerciale au cas où l’autre partie décide de vous poursuivre en justice, ou dans quelle mesure vous êtes protégés si vous recherchez une réparation légale à leur encontre.

La chose clé à comprendre d’une perspective de management de projet est ce que vous devez faire pour éviter des réclamations et des dommages et comment vous devriez aborder des problèmes s’ils se matérialisent pour les empêcher de devenir des litiges. Très peu de sociétés veulent aller au tribunal si elles peuvent l’éviter. En vous familiarisant avec comment votre contrat fonctionne, vous pouvez aider votre organisation à éviter une perte de temps, d’énergie et d’argent que tout litige cause inévitablement .

D’ « arme » à « manuel de l’utilisateur »

dealmakers-book-photoComme vous pouvez le voir, le contrat n’est pas vraiment si différent du plan de projet. Son rôle devrait être de vous aider à livrer un projet réussi et vous supporter dans la décision sur les inévitables problèmes qui surgissent au long du projet. En adoptant le contrat comme « le manuel de l’utilisateur » pour vos relations commerciales, plutôt que juste une arme pour frapper l’adversaire, vous aiderez votre organisation à atteindre ses objectifs de projet et nouerez des relations plus fortes pour l’avenir.

5 June – London – Making transition from Full-Time Employee to Project Management Contractor

20 Apr

Arras People launch a second event in London for project management professionals who are thinking about making the move from permanent employment to becoming a contractor.

The event takes place on Wednesday 5th June from 6.00pm to 9.00pm in the City near Cannon Street.

>> Further details and bookings

ArrasAd

This seminar has been created for senior experienced practitioners due to the increase in project management professionals moving from full-time employment to contractor / consultant roles. There has been an increase in the demand for practical advice on making a successful transition.

Making this move is often seen as high risk – leaving a salaried role for an immediate future filled with uncertainty. To make a successful transition project management practitioners have to consider a variety of factors.

It pulls together 3 different perspectives – training, trade association and recruitment to share their observations and explore what this means, including:

  • Exploring the difference between contracting vs consulting
  • Advice and insights into making the move
  • Change management, leadership and “softer skills” required to meet the expectations organisation
  • Concrete plans Project Managers can start to make before leaving employment
  • Get equipped and ready with practical tips on areas like CV, websites, LinkedIn etc

19 mars – Montréal – la bonne foi dans les relations entre les divers intervenants du domaine de la construction

15 Mar

Logo-PMI MontréalCommunauté de pratique Construction :« L’importance de la bonne foi dans les relations entre les divers intervenants du domaine de la construction »

PDUs : 1.5 avec Martin Sheehan qui expliquera la notion de bonne foi et son application, notamment dans les relations entre les divers intervenants du domaine de la construction. Plus particulièrement, il analysera des décisions récentes qui réitèrent ce principe fondamental qui doit gouverner l’exercice des droits

17H00 RÉSEAUTAGE / 17H30 À 19H00 CONFÉRENCE

Fasken Martineau Du Moulin – Tour de la Bourse – 800 Place Victoria, 37ième étage – Montréal Québec, H4Z 1E9

Pour s’inscrire

rédiger un contrat au forfait sur un projet Agile

18 Jun

Writing a Fixed Contract for an Agile Project

http://www.brighthub.com/office/project-management/articles/125813.aspx écrit par Michael Kirkham-Jones et édité par Michele McDonough

Article précédent sur Agile ou pas

Comment rédigez-vous un contrat au forfait sur une proposition Agile embryonnaire ? Ce n’est pas aussi difficile que certains le font paraître mais cela implique un vrai changement de mentalité et un exercice d’apprentissage pour tout un chacun. Clairement définir « fait » (« done »), évaluer des histoires et comprendre la vélocité sont clés à la réussite.

Ne limitez pas Agile

Si toute l’idée d’Agile est que vous ne pouvez pas prévoir l’avenir, alors comment pouvez-vous l’utiliser dans un Environnement de contrat de forfait où il est essentiel de préciser vos coûts, votre temps et votre contenu de projet ? Peut-être que la réponse est de regarder au-delà de relier Agile à des modèles de contrat mal adaptés et de proposer une nouvelle structure.

OK, donc la chose fondamentale que nous pouvons affirmer de tout ce que nous lisons sur Agile est le fait que les besoins ont vraiment tendance à être très brumeux. Au contraire, le modèle de contrat fixe exige d’un jeu détaillé, stable et précis de besoins, définissant clairement des limites et des pénalités si quelqu’un pose le pied à l’extérieur de celles-ci.

Le faire de façon professionnelle

article précédent sur assistons-nous à la fin des contrats « classiques »?

Comment diable deux animaux si différents peuvent-ils coexister dans le même environnement ? Il y a tant de débat sur comment ceci peut être fait que couvrir chaque idée, pensée ou sentiment nécessiterait des dizaines d’articles. Je pense que ma meilleure approche est de décrire mon expérience et comment je configure un Contrat Agile.

Au tout début d’aborder la question d’Agile et forfait, il était impératif de partir d’une structure logique et professionnelle pour le processus. Je voyais si souvent des présentations où la société a offert une approche de toute évidence biaisée et il n’y avait absolument aucune chance que le projet puisse commencer, encore moins être complété. Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. Un travail bâclé se sent à un kilomètre.

Alors, comment approchons-nous une proposition de contrat au forfait ? La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts. Sur chacun de ces domaines, nous avons alors passé beaucoup de temps à définir et documenter clairement et précisément le quoi et le comment. Pour nous, cela nous a ouvert une structure complètement différente de notre organisation et a potentiellement ajouté de nouvelles sources de revenu.

Le temps et les coûts dans un contrat au forfait sont raisonnablement faciles à définir et pour Agile l’approche itérative a durée contrainte est très facile à définir. Ceci nous laisse donc seulement avec le problème du contenu/portée/périmètre. Comment pourrions-nous fixer les livrables sans étrangler la méthodologie Agile que nous suivons si fièrement ? Le problème était de changer le concept de contenu en un budget.

Définition de l’élément « contenu » du Contrat

La toute première étape était de collecter les besoins des utilisateurs sous forme d’un arriéré de produit en utilisant des histoires utilisateur pour détailler les attentes des clients. Nous utilisons alors cet arriéré de produit pour prioriser puis évaluer les fonctionnalités en utilisant des techniques d’estimation de groupe comme le « Planning Poker » et donner des valeurs sous forme de points d’histoire « Story Points ».

En allant plus loin dans ce processus nous passons 1 à 2 jours à définir :

« L’histoire utilisateur est une façon d’exprimer des besoins qui sont compréhensibles pour les deux clients et nous-mêmes. Les histoires utilisateur sont rapides à écrire et impliqueront tous les niveaux de la structure d’organisation concernée. Elles sont, plus important encore, orientées fonctionnalité, donc elles peuvent fournir une bonne vue du contenu réel d’un projet et nous pouvons les comparer l’une à l’autre en termes de taille, d’effort « , etc [1]

Pour l’estimation, nous avons tendance à utiliser des points d’histoire par opposition aux jours idéaux ( Je discute de ceux-ci dans mon article sur les Burndown Charts). Il est très important de vous assurer que vous avez une vue très claire de « fait » (« done ») et que vous avez une définition explicite et concrète qui forme le point de contrôle critique du projet agile. Sans une compréhension cohérente de « fait » il sera impossible d’évaluer précisément la vélocité. « C’est aussi une façon de construire la confiance avec le client en ayant un consensus commun quant au processus de projet et sur le critère d’acceptation de haut niveau. « [1]

Ici, nous pouvons maintenant inventer une valeur définissant notre budget de contenu avec des points d’histoire. C’est cette valeur qui est fixée dans le contrat et non Pas les histoires.

Alors, combien cela coûtera-t-il et combien de temps sera nécessaire ?

focus sur les coûtsAvec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?

La vélocité de l’équipe est basée sur beaucoup de facteurs, pas seulement combien de travail qu’ils peuvent réaliser. Nos pratiques de travail définissent déjà notre stratégie de communication et nous savons donc combien de temps est passé en réunions planifiées avec l’équipe et le client. Il y a d’autres facteurs à considérer comme les vacances, le volume des tâches, etc. En bout de ligne la vélocité journalière sera un nombre qui est en partie basé sur l’expérience, mais contient pas mal de suppositions (par exemple : si nous sommes en l’hiver, nous pouvons être sûrs que quelqu’un aura la grippe).

Disons par exemple que nous avons calculé que l’équipe peut livrer 30 points d’histoire par itération de 2 semaines et a 240 points d’histoire à livrer (tel que défini dans le contrat). Nous avons maintenant une durée de livraison de 8 itérations nécessitant 16 semaines en tout. Avec 70 heures allouées à chaque itération, une équipe de 5 personnes et un taux horaire de 100 € par membre de l’équipe nous pouvons facilement calculer le prix à 280,000 €.

Donc, maintenant nous avons nos valeurs de contrat fixes :

  • Prix 280,000 €
  • Temps 16 Semaines
  • Contenu 200 points d’histoire

Ces valeurs font tout simplement partie de la procédure tarifaire du contrat et ils ont vraiment tendance à être les chiffres les plus difficiles à atteindre avec un niveau de confiance acceptable.

Ce que nous essayions de montrer ici est que la façon dont nous travaillons sur les projets Agile peut aussi se refléter dans l’environnement des négociations de contrat.

Qu’advient-il si..

… Le propriétaire de produit « product owner » (le client) veut ajouter une autre fonctionnalité ? Nous avons déjà travaillé étroitement avec le client, à définir l’arriéré de produit, évaluer les points d’histoire, donc il connaît la situation actuelle. En cas de demande de travail supplémentaire nous évaluons l’ajout, disons 10 points d’histoire dans ce cas et nous négocions pour soit supprimer 10 points de valeur d’histoire de fonctionnalités agréée soit ajouter une itération de plus. Maintenant que nous avons fixé les points pour le contenu nous pouvons permettre à des changements de se produire, en termes de points. Cela nous permet d’interchanger des besoins en chemin dans la limite de contenu définie. Si nous pouvons rester dans cette limite, nous pouvons aussi rester dans des prix et durée fixes.

… Le client se plaint du prix ? Nous clarifions avec nos équipes de vente que la seule négociation possible dans cette situation est le tarif horaire. Nous ne mettrons pas en péril le projet en essayant d’augmenter la vélocité. Vous ne pouvez pas changer les membres de votre équipe en super-héros en changeant des valeurs sur une feuille de papier.

Et Finalement

Une fois que vous faites signer le contrat et que le travail est en cours, il est impératif que vous managiez vos coûts. Dans mon article sur les Burndown Charts, je discute de comment ceux-ci peuvent être utilisés pour contrôler la vélocité de l’équip. Ils peuvent aussi être utilisés pour contrôler le changement de contenu et les coûts.

Un de mes secteurs de spécialisation est les Contrats au Forfait Agiles, et j’écris et présente sur le sujet régulièrement.

Pour des lecture complémentaires, regardez s’il vous plaît mon Guide to Agile Project Management.

Références

Méta Projets Management

Partenaire de DantotsuPM

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 414 autres abonnés

%d blogueurs aiment cette page :