SIO-1000 / Systèmes et technologies de l'information
Module 2 (Le cycle de vie d'un SIO)
Automne 2022 - Enseignante (Audrey Durocher)

SÉANCE#6
Le dossier d’affaires

Dépendance des organisations aux SIO

Rappel: Les bénéfices potentiels des SIO sont importants:

• Réalisation des activités avec efficacité (résultats bien atteints) et efficience (bonne utilisation des ressources)

• Meilleure prise de décision

• Analyse et la détection des tendances dans l’environnement

La qualité des SIO est de haute importance pour la performance des organisations.

La dépendance des organisations aux SIO augmente et les conséquences liées aux succès et aux échecs des SIO comprennent:

• L’augmentation ou la diminution des revenus

• L’amélioration ou la dégradation de la réputation d’une marque

• L’augmentation ou la diminution de la productivité

Les SIO sont:

• complexes (ils ont souvent plusieurs composantes, utilisateurs, objectifs, etc.)

• invisibles et intangibles (plusieurs composantes du SIO ne sont pas concrètes, et chaque utilisateur a une vision seulement partielle du SIO)

• en évolution continue (les technologies, les besoins, les environnements internes et externes modifient les SIO)

Ceci conduit à repenser les méthodes de projet linéaires (non itératives) qui se révèlent lourdes et lentes dès que la

complexité et la vitesse du changement

deviennent grandes

Risque: évènement qui pourrait mettre en danger le succès du SIO

• On prend des risques dans toutes les activités de la vie quotidienne

• Exemples: en déjeunant (allergies, appareils électriques), en allant travailler (traverser la rue, conduire), etc.

Des besoins complexes et difficile à décrire

Les échecs de projets en SIO

Principales raisons des échecs de projets en SIO:

• Exigences de gestion mal définies ou absentes

• Phases de planification et d’analyse inadéquates

• Manque de leadership dévoué de la part de la haute direction

• Pratiques inefficaces de gestion de projets

« La plupart des échecs proviennent d’une conduite de projet

non professionnelle (conception du système et management du projet)

et non de la réalisation/fabrication du système »

http://www.projectissimo.com/livres-blancs-cles-dun-projet-de-transformation-reussi-pxl-347_177_285.html

Qu’est-ce qu’un projet en SIO ?

Un projet est un ensemble d’activités à effectuer pour atteindre un but défini de façon spécifique

Un projet représente une intention, avec un plan à réaliser

• Projet de voyage

• Projet d’étude

• Projet de recherche

• Projet de transformation

• Projet d’informatisation

Un projet en SIO regroupe l’ensemble des activités permettant la mise en œuvre et la livraison d’un SI dans une organisation.

Le cycle de vie d’un projet en SIO

Deux professions qui se côtoient dans les projets en SIO

Analyste d’affaires

• Analyser, résumer et cerner les besoins des parties prenantes (ensemble des personnes touchées par la solution)

• Faire l’arrimage entre les besoins, les solutions possibles et faire une recommandation de solution

• Jouer le rôle de traducteur entre ces personnes et ceux qui construisent les TI.

Chef de projet

• Responsable d’initier, planifier, réaliser, suivre, contrôler et finaliser le projet en jonglant avec la portée, la qualité, l’échéancier, le budget, les ressources et les risques associés au projet.

• Réaliser et faire le suivi du projet

Source: Project Management Body of Knowledge (PMBOK) du Project Management Institute (PMI)

Business Analysis Body of Knowledge (BABOK) de l’International Institute for Business Analysis (IIBA)

L’importance de la planification avant-projet

Plus une erreur est découverte tard dans le processus de développement, plus elle sera coûteuse à corriger!

Comment faire les bons choix et prioriser les projets en SIO ?

Dans une organisation:

• Plusieurs projets sont effectués en parallèle et/ou sont proposés en même temps

• Les ressources organisationnelles sont limitées

Il y a une forme de compétition entre les projets. En conséquence, les équipes de projet doivent monter un argumentaire pour convaincre les décideurs de l’importance et de la pertinence de leur projet.

Cet argumentaire est appelé un dossier d’affaires ou dossier de décision (IIBA).

Il permet aux organisations de décider quels projets seront réalisés et de prioriser ces projets.

Qu’est-ce qu’un dossier d’affaires ?

Dossier d’affaires et dossier de décision sont synonymes

Le dossier d’affaires:

• Est un document qui sert à justifier un projet

• Démontre comment le projet répond aux objectifs de l’entreprise et des parties prenantes

• N’est pas un dossier technique

• Ne doit pas être trop complexe à lire pour les gestionnaires et les décideurs

L’objectif est de « déterminer si une organisation peut justifier l’investissement nécessaire à la mise en œuvre d’une solution proposée ».

• Doit parvenir à convaincre de la valeur du projet

• Les décideurs doivent être en mesure de prendre une décision d’investissement

Source: Business Analysis Body of Knowledge (BABOK) de l’IIBA

L’analyste d’affaires doit comprendre la structure, les politiques et le fonctionnement de l’organisation et recommander ensuite des solutions, incluant souvent des technologies de l’information (TI), qui permettront à l’organisation de résoudre ses problèmes et d’atteindre ses objectifs.

Son travail consiste donc principalement à:

• identifier, définir, analyser puis documenter les besoins des futurs utilisateurs d’un SI

• trouver une solution à ces besoins d’affaires

Pour y arriver, il utilise une méthode appropriée.

Les qualités de l’analyste d'affaires

L’analyste d’affaires fait le pont entre les fonctions métiers (utilisateurs et gestionnaires) et la fonction TI (programmeurs et informaticiens)

• la documentation (i.e. modèles et textes) produite servira à valider les besoins auprès des futurs utilisateurs

• elle servira aussi à indiquer aux informaticiens quelle application ils doivent construire (ou aux fournisseurs quel logiciel ils doivent fournir)

L’analyste doit ainsi posséder des :

• connaissances d’affaires

• connaissances TI

• habiletés de communication

• capacités d’analyse

Les stratégies de réalisation des projets

Cycle de vie du développement

Source "Définir le dossier de décision", BABOK Guide, pp. 110-113

Définir le dossier de décision
5.5.1 Objet
Déterminer si une organisation peut justifier l’investissement nécessaire à la mise en œuvre d’une solution proposée.

5.5.2 Description
Le dossier de décision sert à justifier un projet : la valeur ajoutée à l’entreprise grâce à la solution déployée comparativement à son coût de développement et de mise en œuvre. Ce dossier peut aussi contenir une description des avantages quantitatifs et qualitatifs, une estimation des coûts et du délai pour atteindre le seuil de rentabilité, les attentes en matière de profits et le suivi des possibilités. Il peut aussi présenter les conséquences prévues sur le flux de trésorerie des mesures prises, au fil du temps, ainsi que les méthodes et les justifications utilisées pour quantifier les avantages et les coûts. Le dossier de décision procure ainsi un cadre qui montre comment l’initiative devrait répondre aux objectifs de l’entreprise. Il énumère en outre les contraintes liées au projet proposé, ainsi qu’une estimation du budget et l’harmonisation avec les stratégies de l’organisation.

5.5.3 Intrants
Hypothèses et contraintes : les hypothèses sur le revenu produit ou maintenu grâce à la solution ou les améliorations non financières qu’assure la solution en font partie.
Besoin d’affaires : il définit la valeur qu’une solution apportera à l’organisation et comment elle s’harmonisera avec ses buts et ses objectifs.
Portée de la solution : elle définit les capacités qui seront implantées, les méthodes utilisées à cette fin et les secteurs visés de l’organisation.
Préoccupations des parties prenantes : elles peuvent comprendre les risques ou les enjeux dont il faut tenir compte dans le dossier de décision

Figure 5-7 : Diagramme des intrants/extrants de l’activité Définir le dossier de décision

5.5.4 Éléments
.1 Avantages
Mesurer les avantages de la solution recommandée en termes de gains qualitatifs et quantitatifs pour l’entreprise. Si possible, il est préférable de quantifier les avantages. Les avantages de nature autre que financière (p. ex. personnel plus motivé, meilleure capacité d’adaptation au changement, satisfaction accrue de la clientèle ou réduction de l’exposition au risque) sont aussi importants et ajoutent une valeur considérable à l’organisation, même si leur évaluation est qualitative. Les estimations des avantages sont directement liées aux buts et aux objectifs stratégiques de l’entreprise.
.2 Coûts
Estimer le coût net total de la solution. Pour ce, il faut des estimations des dépenses en immobilisations du nouvel investissement; des coûts d’élaboration et de mise en œuvre du changement; des coûts de renonciation à d’autres options; des coûts liés au changement du travail et des pratiques de l’organisation; du coût total de la propriété de la nouvelle solution et des coûts indirects assumés par d’autres.
.3 Évaluation du risque
La première évaluation de risque sert à déterminer si l’initiative proposée fait courir plus de risques que l’organisation est disposée à prendre. Elle est principalement axée sur les risques liés à la faisabilité de la solution et est revue tout au long du projet. L’évaluation du risque doit tenir compte des risques techniques (à savoir si la technologie et les fournisseurs choisis peuvent fournir la fonctionnalité requise), des risques financiers (à savoir si les coûts peuvent dépasser la limite à l’intérieur de laquelle la solution est viable ou les avantages potentiels susceptibles de disparaître), des changements dans l’entreprise et des risques organisationnels (l’organisation apportera-t-elle les changements nécessaires pour tirer profit de la nouvelle solution?).
.4 Mesure des résultats
Le dossier de décision ne fait pas qu’exposer les coûts et les avantages à venir, il indique aussi comment ceux-ci seront estimés et évalués.

5.5.5 Techniques
Analyse décisionnelle (9.8) : l’analyse coûts-avantages compare les coûts de mise en œuvre d’une solution et les avantages qui en découleront. L’analyse financière comprend l’utilisation de modèles financiers qui permettent d’estimer la valeur marchande d’un actif de l’organisation.
Estimation (9.10) :elle permet d’estimer l’ampleur de l’investissement nécessaire pour déployer et utiliser la solution proposée. Mesures et indicateurs clés de la performance (9.16) : ils sont évalués pour appuyer la gestion des avantages, la mesure et l’établissement des rapports, y compris les situations dans lesquelles il faut réaligner les mesures ou les systèmes internes pour qu’il soit possible d’observer, d’évaluer et de concrétiser les comportements recherchés.
Analyse de risque (9.24) : elle sert à évaluer les risques susceptibles d’influencer la solution, ainsi que les coûts et les avantages qui s’y rattachent.
Analyse FFOM (9.32) : elle montre comment la solution aidera l’organisation à maximiser ses forces et à réduire ses faiblesses au minimum.
Évaluation du fournisseur (9.34) : si l’achat ou l’externalisation à une tierce partie est envisagé, une évaluation du fournisseur pourra faire partie du dossier de décision.

5.5.6 Parties prenantes
Promoteur du projet : il approuve le dossier de décision et autorise le financement.
Expert du domaine : il participe à l’estimation des avantages que retirera l’entreprise de la nouvelle initiative.
Expert du domaine dans la mise en œuvre : il participe à l’estimation des prévisions de coûts de la technologie à mettre en place pour implanter la nouvelle solution.
Gestionnaire de projet : il participe à l’élaboration des estimations des coûts et du délai d’exécution et peut dresser un plan préliminaire du projet ou une structure de découpage des tâches en collaboration avec l’équipe de projet. Il utilisera le dossier de décision comme intrant de la charte de projet.

5.5.7 Extrant
Dossier de décision : il présente l’information nécessaire à la décision d’investir ou non et de réaliser le projet proposé.

SÉANCE#7

La gestion des projets en SIO

La charte de projet

Lorsqu'une entreprise a sélectionné ses projets d’investissement et a identifié son chef de projet, il est temps de construire le projet.

La décision d’investissement se concrétise par la rédaction de la charte de projet. Ce document autorise formellement le projet et donne au chef de projet l’autorité pour réaliser le projet (affectation des ressources organisationnelles au différentes tâches du projet).

La charte de projet est composée de plusieurs éléments. Les principaux sont:

• La portée du projet : permet de définir le travail à accomplir. Elle réitère la nécessité du projet et reprend plusieurs éléments du dossier d’affaires qui sont revus et approfondis (les objectifs du projet, les besoins et les exigences, l’étude de faisabilité)

• Objectifs du projet : Les objectifs du projet sont énoncés sous la forme de critères quantifiables pour pouvoir mesurer la réussite du projet

• Extrants (ou livrables) : Objet, document ou résultat vérifiable qui est produit pour terminer un projet ou une partie d’un projet

• Jalons : dates clés auxquelles certaines activités doivent être exécutées

Le plan de gestion du projet

Le plan de gestion du projet est un document qui décrit la gestion et l’encadrement de l’exécution d’un projet.
La bonne communication du plan de projet est primordiale. Il doit être facile à lire et à comprendre et être communiqué à toutes les parties prenantes.
Le plan de projet doit inclure:

• Un rappel de la portée du projet

• La liste des activités qui composent le projet

• Un calendrier de projet (échéances et jalons)

• Une estimation de la durée et du coût du projet (par activités)

• Les ressources prévues

• Les affectations de tâches et le partage des responsabilités

• Un plan de communication

Il faut aussi prévoir les facteurs de risque du projet et les stratégies de mitigation des risques (ce qui inclut des plans de contingence et des mécanismes pour déclencher l’arrêt du projet).

Les chefs de projets doivent continuellement contrôler et évaluer les projets pour mesurer leur succès. Il faut être en mesure de :

• Décider rapidement de mettre fin à un projet

• Minimiser les dépenses inutiles

• Réaffecter les ressources libérées à d’autres projets ayant plus de valeur

Les acteurs des projets en SIO

Source: http://www.fonctionnel.net/analyse-fonctionnelle/acteurs-projet-informatique#.Uh5VNqzVNHZ

Des projets simples aux complexes

À la base, pour un petit projet, nous avons besoin minimalement de deux acteurs : un client et un informaticien. Le client énonce un besoin, il a des objectifs et veut que son travail (ou celui de ses employés) soit plus efficace. Il voit un retour sur l'investissement, en payant les services de l'informaticien qui lui automatisera une partie de ses processus, il voit un gain sur son service à la clientèle, sur ses coûts de production ou autre.

L'informaticien, dans ce genre de projet, fait tout de A à Z. Il prend les besoins, conçoit une solution en collaboration avec le client. Il évalue les coûts et estime le temps que le développement lui prendra. Il programme l'application ou le système désiré. Il fait des essais unitaires, fonctionnels et systèmes. Il installe le système et ses mises à jour, fait la formation et supporte les utilisateurs.

Ensuite, le projet prend de l'ampleur, l'informaticien seul ne suffit plus. Il a le temps que pour prendre les besoins et concevoir des solutions. Il se spécialise alors (s'il a de l'intérêt) en analyste fonctionnel. Puisqu'il n'a pas le temps de réaliser le système, un second informaticien vient l'aider pour programmer, il s'agit d'un programmeur. L'analyste fonctionnel fourni au programmeur des dossiers fonctionnels qui contiennent toutes les spécifications sur le système attendu. Le programmeur écrit le code du système, fait les compilations et installations.

Du côté du client, lui non plus ne suffit plus. Il nomme deux personnes. L'analyste d'affaires est spécialement dédié pour consigner le besoin des utilisateurs, et la vision de la direction de l'entreprise. Il priorise les besoins et évalue les impacts sur l'entreprise. Le pilote de système est en quelque sorte un super utilisateur. C'est lui qui fait les configurations avancées dans le système, c'est aussi lui la personne de référence pour les utilisateurs lorsqu'ils ont des problèmes ou questions avec le système. Cette personne est aussi responsable de faire des essais utilisateurs avant les mises en production du système.

Un chargé de projet s'ajoute aussi à l'équipe. Son rôle est d'encadrer l'équipe de développement afin de s'assurer de respecter les échéanciers et les budgets. Généralement, il assure une direction forte en début de projet pour bien aiguiller son équipe. Par la suite, c'est l'équipe de développement elle-même qui prendra davantage la direction lorsqu'elle maitrisera bien le projet. Le chargé de projet a un rôle de facilitateur. Il aide les personnes à communiquer entre elles et contribue à trouver des solutions lorsqu'il y a des valeurs qui entrent en conflit. Il s'assure constamment que le développement avance bien.

Dans une plus grosse équipe, il y a plus de gens. Qui dit plus de gens, dit nécessairement structure hiérarchique. Non pas nécessairement dans le sens d'autorité, mais davantage dans le sens d'efficacité. Arrivent alors les architectes : l'architecte d'affaires, l'architecte fonctionnel et l'architecte organique. Ils travaillent sur les besoins et les solutions à haut niveau, laissant le détail aux autres intervenants. Ils s'assurent de la cohérence de tout ce qui est fait. Ils aident pour l'évaluation des temps. Ils recensent et pèsent les impacts avant qu'un ajout ou une modification d'une fonctionnalité soit fait au système selon leur secteur (affaires, fonctionnel ou organique). Ils prennent ensemble les grandes décisions quant aux orientations à appliquer. Ils répondent aux questions des membres de leur équipe, encadrent les nouveaux venus, diffusent les informations des décisions prises dans les comités et sollicitent de l'aide aux gens de leur équipe pour faire des prototypes et des simulations.

Parallèlement à l'équipe de développement (incluant ceux qui fournissent le besoin), il y a une équipe dite technologique. Celle-ci travaille à répondre aux besoins matériels et configurations logicielles. Ils déterminent les machines (ordinateurs) à mettre en place pour faire exécuter le système, effectuent les tests de charges, définissent les plans de relève et de sauvegarde et sont présents pour faire les mises en production.

À tout ce monde, s'ajoutent d'autres personnes qui ont des spécialités diverses :

• L'administrateur de base de données (DBA) travaille à ce que la base de données soit cohérente et performante;

• Un ergonome s'assure que les interfaces utilisateurs sont présentées de manière constante, claire, et efficace aux l'utilisateur. Ce dernier fait des tests d'utilisabilité;

• Un graphiste définit les couleurs et produit les images utilisées pour présenter le système;

• L'intégrateur veille à ce que l'arrimage entre les composantes logicielles et/ou systémiques fonctionne bien;

• Les experts en méthodologie aident les équipes à mieux organiser leur travail;

• Les préposés au support aux utilisateurs sont les premiers répondants lorsque les utilisateurs ont des difficultés avec l'utilisation du système;

• Les testeurs (ou responsables en contrôle qualité) conçoivent et réalisent des plans d'essais et s'assurent de la non-régression du système pendant son évolution;

• Etc.

Organisation d'entreprise vs organisation de travail

Généralement, dans les grandes entreprises, ministères ou organismes, tout ce qui touche l'informatique (ou technologie de l'information) fait partie d'une même division administrative. Puis, tout ce qui touche utilisateur, pilotage et ligne d'affaires fait partie d'une autre division administrative. Ces divisions « verticales » ont du sens en termes d'administration et de gestion d'entreprise pour l'organisation des ressources, du budget, etc.

Or, dans le cadre d'un projet, la division se fait davantage de manière « transversale » où les différents individus, de différentes divisions administratives, doivent coopérer et communiquer pour mettre à bien le projet.

Le défi se trouve exactement là. Les politiques et les façons de faire propres à chaque unité administrative dictent les rôles et responsabilités de chacun au sein de leur division, et non pas leur rôle et responsabilités au sein du projet. Lorsqu'une direction forte n'est pas assurée entre les divisions, cela donne lieu à des frictions internes. Un exemple simple pourrait être que l'équipe TI reproche aux utilisateurs de ne pas énoncer leurs besoins clairement, et de l'autre, les utilisateurs pourraient reprocher à l'équipe TI de ne pas fournir assez d'information sur ce qui est possible ou non de faire, afin de pouvoir les éclairer à prioriser et définir leur besoin.

Consultants et internes

Tous les membres de l'équipe travaillent en finalité pour le client. Ils sont soit employés de celui-ci (interne) ou fournisseur de service pour celui-ci (consultant). Ce statut, consultant ou interne, n'a pas d'impact dans le travail de tous les jours au sein d'une équipe. Mais il faut voir tout de même certaines distinctions :

Long terme : les employés (internes) sont engagés pour du long terme. Ils développent l'expertise au sein de l'entreprise et sont en quelque sorte les gardiens du patrimoine applicatif. Ils maîtrisent mieux que qui conque les systèmes en place.

Le court terme : À l'inverse, pour du court terme ou avoir une expertise spécialisée, les consultants sont l'idéal. Leur expérience n'est pas dans l'entreprise, mais une somme d'expérience dans diverses entreprises qui permet d'amener un regard nouveau aux employés internes.

Le gestionnaire de projet

Son travail consiste principalement à:

• mener à bien le projet

• planifier les activités à réaliser, les besoins en ressources, estimer les coûts, élaborer les méthodes de suivi, etc…

• assurer le contrôle et réagir rapidement aux changements en cours de projet (faire le suivi)

Pour y arriver, il doit utiliser une méthode et des outils appropriées, mais aussi ses connaissances, aptitudes et compétences, afin de:

• mettre en place un système de communication efficace

• diriger, animer, motiver et développer son équipe

Les connaissances et compétences nécessaires au gestionnaire de projet

Est-ce que le gestionnaire de projet en SIO doit posséder des connaissances en technologie et en développement de logiciel ?

• Si le gestionnaire n’a pas ces connaissances, il peut être mis en doute par son équipe qui le croit inutile/incompétent/etc.

• Le gestionnaire peut avoir de la difficulté à bien mener le projet à terme dû à une incompréhension des taches et activités à effectuer.

En résumé

La gestion de projet, c’est l’application de connaissances, d'habiletés, et l’utilisation d'outils et de techniques pour planifier des activités afin de satisfaire les exigences du projet.

La gestion de projet comprend :

• L'identification des bénéfices et des besoins

• L’établissement d’objectifs clairs et réalisables

• L’étude de la faisabilité du projet (risques et enjeux)

• La réalisation de l'équilibre entre les attentes concurrentes au niveau de la qualité, des délais et du coût

• L’adaptation des spécifications du plan de gestion du projet aux différentes préoccupations et attentes des parties prenantes

• Le suivi et le contrôle du projet pour s’assurer de son succès

Les projets en SIO peuvent être réalisés à l’interne ou à l’externe.

L’externalisation requiert une gestion particulière du projet et de la relation avec les fournisseurs de services, afin de tirer profits de ses avantages et de minimiser les risques qui y sont associés.