Chaque projet informatique suscite une série de questions auxquelles les chefs de projet et les DSI doivent trouver des réponses : quels moyens mettre en œuvre ? Quel chiffrage retenir ? Quel planning appliquer ? Quels sont les risques ? Quels sont les aspects fonctionnels à privilégier ?
Ce livre apporte les éléments pour répondre au mieux à toutes ces questions. Selon l’auteur, responsable des développements logiciels chez LexisNexis : « Un projet est un processus professionnel limité dans le temps et qui fédère les contributions de ses membres pour atteindre un but (par exemple aider à réaliser une vente, faire évoluer le système d’information…).
Participer à un projet, c’est se figurer quel sera le résultat final. (…) la conduite de projet est la maîtrise de ce processus. » Avec un ensemble de moyens : techniques, humains, financiers et généraux.
Les contraintes sont fixées par le cahier des charges, la maîtrise des coûts, de la qualité et des délais. Concernant le cahier des charges, l’auteur pointe un « curieux paradoxe » : « Ce document est souvent cité comme l’unique (et indispensable) contrainte d’un projet, mais en même temps, il est critiqué pour ses prétendues lacunes et imperfections : manque de clarté, d’exhaustivité, de précision, ou alors trop schématique, trop général, trop large ou trop précis ! » L’auteur conseille de considérer le cahier des charges comme étant principalement « un recueil fonctionnel, ainsi qu’un ensemble de spécifications techniques qui forment un cadre de travail ».
Conduite de projets informatiques, développement, analyse et pilotage, par Brice-Arnaud Guérin, éditions ENI, 2009, 297 pages.
Trois modèles
Un projet s’articule selon trois axes : le temps (le développement, depuis l’expression des besoins jusqu’à la livraison et la maintenance), l’analyse (vision conceptuelle) et le pilotage. En matière de modèle de développement, « il n’y a pas de bon ou de mauvais modèle », assure l’auteur, du moins parmi les principales approches : modèle en cascade (chaque étape suit la précédente), en V (amélioration du modèle en cascade sur le plan des tests fonctionnels, au prix d’un allongement de la durée du projet), modèle itératif (anticipation des tests d’intégration pour diminuer les risques techniques), modèle RAD (Rapid Application Development), modèle Extreme Programming (cycles courts de production intermédiaire), modèle RUP (Rational unified Process)… à noter que l’auteur n’aborde pas les méthodes de développement agiles.
Le modèle d’analyse, pour sa part, « régit l’étude du système en devenir », avec Merise et UML comme méthodes les plus courantes. La modélisation s’effectue en trois étapes : l’abstraction (analyser l’existant pour en dégager l’essentiel, sans introduire de biais), l’instanciation (les instances étant des objets) et la vérification.
Enfin, l’auteur précise : « Le modèle de pilotage a pour objet de prévoir la survenue d’aléas et d’anticiper des changements critiques du processus de projet. Cela signifie que le comité de pilotage implique une partie seulement de l’équipe projet, généralement le chef de projet, mais aussi des représentant du comité de direction ainsi que des membres des organisation associées au projet ».
La vie d’un projet se décompose en cinq grandes phases :
- Le démarrage : appel d’offres, premiers choix (cadrage du projet, analyse préalable des risques, choix des modèles de projets, organigramme des tâches), structuration du projet (dimensionnement, maîtrise d’ouvrage et maîtrise d’œuvre, externalisation des ressources, plates-formes techniques).
- L’analyse : domaines métiers (bases de données et modèles d’analyse), périmètre fonctionnel (processus et flux de travail, cartographie fonctionnelle, modèles d’analyse et outils de modélisation, contexte technique, documentation…).
- Le développement du projet : qualité du code, gestion des versions, tests, industrialisation.
- La planification : estimation des charges, emploi du temps du chef de projet, gestion des ressources, planification.
- Le suivi et le pilotage : réunions de projet, comptes-rendus, documentation, gestion des imprévus (techniques, conflits), comité de pilotage, livrables, recette, formation, support, maintenance…
| Gestion de projet : techniques de résolution des conflits | |||
| Technique | Commentaire | Adapté si… | à éviter si… |
| Pourrissement | Le chef de projet diffère son action jusqu’à la disparition du problème ou la survenue de conditions plus favorables, quitte à nier l’existence du problème. | Les enjeux à court terme restent mesurés, et si, objectivement, l’attente paraît raisonnable et profitable. | Une décision peut être prise dans un bref délai. |
| Durcissement | Le chef de projet prend des mesures coercitives pour imposer une solution, indépendamment des raisons invoquées par les parties opposées. | Les parties s’opposent sur des domaines qu’elles maîtrisent mal en réalité. | Le chef de projet n’a pas de vision d’ensemble du problème et ne peut pas apporter d’aide réelle. |
| Négociation directe | Le chef de projet somme les parties de négocier directement la remise à plat de leurs différends. | Les parties doivent avoir chacune des éléments à mettre dans la balance. | Les différends sont trop importants pour que la négociation soit sincère. |
| Médiation | Le chef de projet choisit un médiateur pour négocier une solution. | Le médiateur jouit d’une réputation d’impartialité et de conseil avisé. | La négociation directe suffit. |
| Lâcher prise | Le chef de projet ordonne à l’une des parties de renoncer à ses prétentions. | Le coût d’accès aux exigences concernées est conséquent au vu des conditions courantes. | Le lâcher prise ne doit pas masquer un pourrissement déguisé. |
| Transaction | Le chef de projet concède sans contrepartie certaines attentes d’une partie. | Le chef de projet peut donner des gages et des explications quant au bien-fondé de sa démarche. | La transaction ne doit pas paraître démesurée ni entamer l’impartialité du chef de projet. |
| Source : Conduite de projets informatiques, développement, analyse et pilotage, par Brice-Arnaud Guérin, éditions ENI, 2009, 297 pages. | |||