Le temps est venu de migrer la technologie de plusieurs de vos applications existantes et votre directeur TI ne jure que par le Web, il veut que toutes vos nouvelles applications (ou presque…) soient « Web ». Son argument majeur étant que toutes ces applications web seront beaucoup plus faciles à déployer et à maintenir et que nous sauverons donc des frais importants sur ces deux plans.
On ne compte plus le nombre de projets TI qui se sont soldés par un échec relatif : échec sur le plan des budgets et / ou des échéances, cela est assez commun au point où cela semble être presque perçu comme normal aujourd’hui, même si ça ne devrait pas être le cas. Ce dont on parle moins souvent toutefois, c’est des échecs sur le plan des attentes du Client.
La raison en est fort simple; lorsqu‘il y a divergence sur ce plan entre le Client et le développeur TI, le processus de développement logiciel amène presque toujours les deux parties à conclure que des besoins nouveaux sont apparus en cours de projet ou que des besoins initiaux n’ont tout simplement pas été identifiés à l’origine du projet.
Ces deux hypothèses de travail couvrent une large partie des cas mais pas tous et la réalité est parfois toute autre et aussi toute simple !
Michel Martel, entrepreneur de métier, et analyste-programmeur de formation, ne cesse de parfaire, peaufiner, raffiner sa Gestion de Projets afin de toujours en assurer l’alignement avec les objectifs d’affaires.
Analystik a d’ailleurs investi massivement ces dernières années dans la mise en place de la méthodologie Agile-SCRUM mais aussi dans la formation / certification CMMI ! Et la raison en est fort simple, malgré tout ce que l’on peut dire, aux dernières nouvelles, les statistiques sont toujours les mêmes en termes de Gestion de Projets TI; plus de 83% dépassent soit les budgets, soit les échéances… parfois les deux !
Quelle en est la cause ? Quels en sont les causes ? Difficile à dire; cependant, on peut essayer d’identifier les écueils à éviter au démarrage d’un projet TI ?
La 2e question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à « maintenir » cette application ? Dans ce dernier billet, nous nous concentrerons principalement sur l’Architecture alors que nous avons couvert la Documentation dans le billet précédent.
La liste des facteurs ayant un impact sur les coûts d’entretien d’une application TI ne se limite pas à ces deux facteurs, mais ce sont, à notre avis, les deux principaux.
C’est l’autre question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à « maintenir » cette application ? Dans ce cas-ci, par contre, la réponse ne relève pas de mille et un facteurs mais bien de deux facteurs dominants qui feront varier le coût d’entretien; soit, principalement, l’architecture et la documentation !
S’agit-il d’un billet sur la Gestion de Projets ? Loin de là. Et Dieu sait que la gestion de Projets a fait couler beaucoup d’encre en TI depuis une décennie et que cela mériterait toute une série de billets en soi… que nous ferons peut-être en 2010. Mais pour les besoins de ce billet, nous prendrons pour acquis que tous les développeurs appliquent de bonne pratique en matière de Gestion de Projets.
La liste des facteurs ayant un impact sur les coûts d’entretien d’une application TI ne se limite pas à ces deux facteurs, mais ce sont, à notre avis, les deux principaux.
C’est la question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à développer cette application ? Malheureusement, la réponse n’est jamais simple et jamais unique car il y a mille et un facteurs qui en feront varier le coût… dont la méthodologie de travail et la notoriété de l’entreprise soumissionnaire ne sont pas les moindres !
Le client saisit-il bien toutes les subtilités et les implications sur le plan du développement logiciel de ses objectifs d’affaires ? Veut-il une couche importante d’Intelligence d’Affaires ? Quelle est la nature et l’état de son environnement TI actuel ? Y a-t-il conflit en perspective ou incompatibilité entre l’application souhaitée et les systèmes / applications en place ? Faudra-t-il développer d’autres applications ou mettre en place d’autres systèmes afin d’arrimer cette application ? Dans quelle mesure, cette application est-elle critique à l’atteinte des objectifs d’affaires de l’entreprise du client et si c’est le cas, devrons-nous remplacer certains systèmes en place ou en implanter d’autres ? Devrons-nous optimiser certains processus des applications en place afin d’harmoniser l’interaction avec l’application développée ? Quelle méthodologie le développeur utilisera-t-il ? Quelle est l’architecture retenue ?
S’agit-il d’un billet sur la Gestion de Projets ? Loin de là. Et Dieu sait que la gestion d Projets a fait couler beaucoup d’encre en TI depuis une décennie et que cela mériterait toute une série de billets en soi… que nous ferons peut-être en 2010. Mais pour les besoins de ce billet, nous prendrons pour acquis que tous les développeurs appliquent de bonne pratique en matière de Gestion de Projets.
La pénétration des TIC en entreprise et le rôle stratégique qu’elles ont acquis dans le développement des affaires font en sorte qu’aucun projet TI n’est un vase clos. J’entends par là que tout projet TI a un impact sur d’autres départements et/ou applications et/ou processus d’affaires et/ou ressources que ceux et celles qu’il touche directement.
Conséquemment, la gestion d’un projet TI consiste aussi en bonne partie à gérer les relations avec d’autres départements, les impacts sur d’autres applications et d’autres processus ainsi que sur d’autres ressources.
Il n’est pas toujours facile de naviguer sur des mers dont on ne connaît pas toujours bien les courants !!! Alors comment vous en tirer sans froisser qui que ce soit et sans nuire à la productivité de l’entreprise et de ses ressources ?
