Secrétariat du Conseil du Trésor du Canada
Symbole du gouvernement du Canada

ARCHIVÉ - Définition de la base de référence - Sommaire et analyse des pratiques concernant les projets en technologies de l’information à l’échelle gouvernementale

Avertissement Cette page a été archivée.

Information archivée dans le Web

Information archivée dans le Web à  des fins de consultation, de recherche ou de tenue de documents. Cette dernière n’a aucunement été modifiée ni mise à  jour depuis sa date de mise en archive. Les pages archivées dans le Web ne sont pas assujetties aux normes qui s’appliquent aux sites Web du gouvernement du Canada. Conformément à  la Politique de communication du gouvernement du Canada, vous pouvez demander de recevoir cette information dans tout autre format de rechange à  la page « Contactez-nous ».

Annexe 1

Questionnaire

Rapport d'�tape sur les pratiques des projets du gouvernement f�d�ral

Questions li�es � la gestion de projets

  1. Principe : les projets en technologies de l'information sont ax�s sur les orientations et les priorit�s des secteurs d'activit�, et les appuient.

    • L'approbation du projet est-elle fond�e sur une analyse de rentabilisation qui �tablit un lien direct entre l'investissement et la fonction de gestion, et qui d�montre les avantages de l'investissement tant pour le minist�re que pour le gouvernement dans son ensemble?
    • Un mod�le d'analyse de rentabilisation est-il appliqu� pour tous les projets?
    • Existe-t-il une proc�dure �tablie pour proc�der � l'analyse de rentabilisation, obtenir les approbations, examiner les r�sultats de l'analyse, etc.?
    • L'analyse de rentabilisation sera-t-elle examin�e et valid�e de nouveau lors de chaque �tape du processus ainsi que chaque fois que le projet ou la fonction de gestion fait l'objet d'un changement important?

  2. Principe : les responsabilit�s sont clairement d�finies.

    • Les responsabilit�s globales du minist�re sont-elles d�finies dans la charte du projet?
    • Existe-t-il un mod�le de charte de projet utilis� pour tous les projets?
    • Existe-t-il une proc�dure �tablie pour r�diger le charte du projet, d�finir les r�les et les responsabilit�s des intervenants, obtenir les approbations requises, etc.?
    • Est-ce que toutes les fonctions et les responsabilit�s de base de gestion de projets sont confi�es � des gestionnaires de l'�tat? (Il est question ici des fonctions de base de gestion et de contr�le touchant la planification, la port�e, le d�roulement, le co�t, la qualit�, les risques, les ressources humaines, les approvisionnements, les march�s et les communications.)
    • S'il est n�cessaire de recourir � l'impartition pour certaines fonctions de base de gestion du projet, a-t-on fait appel � un fournisseur autre que celui ayant particip� au march� principal?

  3. Principe : les gestionnaires de projet sont form�s dans une disciple particuli�re et travaillent dans cette sph�re d'activit�s.

    • Le gestionnaire de projet d�sign� a-t-il les connaissances, les comp�tences et l'exp�rience n�cessaires correspondant � l'envergure et � la complexit� du projet de m�me qu'� son profil de risques?
    • Les comp�tences exig�es des gestionnaires de projets sont-elles bien d�finies?
    • Existe-t-il une proc�dure �tablie d�finissant le profil de formation et de perfectionnement des gestionnaires de projet?

  4. Principe : les d�cisions en mati�re de gestion de projet sont fond�es sur la gestion des risques.

    • Le projet est-il dot� d'une s�rie de points de v�rification ou d'�tapes fix�s � l'avance, de sorte que la direction puisse se prononcer relativement � sa poursuite et prendre les correctifs qui s'imposent?
    • Le cycle de vie du projet d�fini par le minist�re �tablit-il � quel moment il faudrait pr�voir des points de contr�le et quels seront les crit�res applicables pour la poursuite du projet?
    • N'a-t-on affect� au projet que les fonds n�cessaires pour atteindre l'�tape suivante?
    • A-t-on utilis� une m�thode d'�valuation des risques conforme aux pratiques �nonc�es dans le SEI's Continuous Risk Management Guidebook, un guide sur la gestion continue des risques, pour d�gager et �valuer les risques associ�s au projet?
    • Existe-t-il une proc�dure �tablie de gestion des risques (comportant des outils, des techniques et des pratiques) obligatoire pour tous les projets?
    • La complexit� du projet a-t-elle �t� �tablie d�s le d�but du projet � l'aide de l'analyse des points de fonction (APF)
    • Se sert-on d'un outil de mesure du rendement ax� sur la norme nationale CSPM pour fournir au gestionnaire de projet (de l'�tat), � intervalles fr�quents, des donn�es sur l'avancement des travaux, les sommes d�pens�es et les �tapes franchies?
    • Les agents d'acquisition de TPSGC ont-ils particip� d�s le d�but de la planification du projet, afin de mettre au point un processus d'acquisition qui permet d'�liminer les retards et de dresser un plan d'acquisition qui harmonise mieux le plan d'adjudication du march� avec le plan du projet?

    Questions li�es � la conception de syst�mes et l'acquisition de logiciels

    Dans ce questionnaire, la conception de syst�mes et l'acquisition de logiciels porte sur la transformation d'un besoin op�rationnel en une description de la configuration d'un syst�me (y compris ceux achet�s) qui r�pond le mieux possible � ce besoin et regroupe les efforts de tous les secteurs et sp�cialit�s (conception logicielle, infrastructure, etc.) afin de produire un logiciel.

    • Existe-t-il une proc�dure �tablie pour d�couvrir, analyser et communiquer les attentes et les besoins des clients de fa�on � mieux savoir comment les satisfaire? (Cette proc�dure �quivaut � l'�tape d'analyse des besoins du syst�me d'un cycle de vie de syst�me traditionnel.)
    • Existe-t-il une proc�dure �tablie reliant les besoins fonctionnels aux diff�rentes fonctions syst�miques (objets, personnes, processus d'appoint, produits et services) dans le cadre des activit�s de conception du syst�me ou de la s�lection de solutions toutes pr�tes? (Cette proc�dure �quivaut � l'�tape de la conception de syst�mes.)
    • Est-ce que des solutions de rechange sont examin�es avant le choix d'une solution pour r�soudre le probl�me fonctionnel, compte tenu des contraintes en jeu? (Cette proc�dure �quivaut � l'analyse de faire ou faire faire souvent effectu�e lors de l'�tape de conception du syst�me.)
    • �tablit-on les besoins au plan de l'architecture technique dans le cadre des activit�s de conception du syst�me?
    • Est-ce que les projets d'achat de logiciels d�notent autant de rigueur que l'�laboration des projets, ce qui comprend l'�tablissement d'un budget et d'un calendrier, la gestion des risques et l'�valuation de la performance?
    • Existe-t-il des directives et une proc�dure consign�es pour l'achat de logiciels (c'est-�-dire, normes des produits, besoins et contraintes au plan de l'architecture, etc.)?
    • Concernant l'achat de logiciels, pr�voit-on une p�riode de transition pour la mise en œuvre de ceux-ci?
    • Existe-t-il une proc�dure �tablie d'int�gration et d'�valuation de syst�mes afin de veiller � ce que les �l�ments du syst�me fonctionnent comme un tout? (Cette proc�dure consiste d'abord � d�finir et � contr�ler les interfaces ainsi qu'� v�rifier les fonctions du syst�me qui font appel � plusieurs �l�ments.)

    Questions li�es au mod�le d'�volution des capacit�s (CMM)

  5. La gestion des exigences exige la r�daction et le maintien d'une entente avec le client sur les exigences, techniques et autres (p. ex. date d'�ch�ance), du projet.

    • Est-ce que les clients, la direction du projet et l'�quipe de projet conviennent des exigences � respecter?
    • Les exigences sont-elles document�es et les documents mis � la disposition de tous les membres de l'�quipe de projet?
    • Les modifications touchant les exigences sont-elles prises en compte dans les estimations des co�ts et des travaux n�cessaires pour r�aliser le projet ainsi que dans l'estimation de la taille du produit?
    • Les modifications concernant les exigences sont-elles n�goci�es entre les clients, la direction du projet et l'�quipe de projet, et accept�es de tous?
    • �tablit-on des rapports entre les exigences et les composantes de la conception, les �l�ments de codage et les plans et processus d'essai?
    • Les exigences sont-elles analys�es pour en d�terminer l'int�gralit�, la clart�, l'uniformit� et la faisabilit�?

  6. La planification de projets exige la pr�paration de donn�es estimatives pour le travail � ex�cuter, les engagements � respecter et l'�laboration du plan d'ex�cution du travail.

    • Les activit�s du projet sont-elles d�finies et document�es dans un plan (plan du projet)?
    • Existe-t-il des proc�dures ou des lignes directrices pour �valuer les co�ts et les travaux n�cessaires � la r�alisation du projet, et pour estimer la taille des produits?
    • Les engagements de groupes externes sont-ils consign�s et font-ils l'objet d'un accord de la part des groupes concern�s (c.-�-d. gestion des configurations et de la documentation, assurance-qualit�, clients et sous-traitants)?
    • Le plan du projet est-il examin� par le gestionnaire de projet, les gestionnaires des autres groupes concern�s et les membres de l'�quipe de projet?
    • Est-ce que les risques associ�s au projet (co�ts, ressources, calendrier, aspects techniques) sont d�finis, �valu�s et document�s?
    • Les activit�s pr�vues correspondent-elles � un cycle de vie bien d�fini?
    • A-t-on pr�vu, obtenu ou pr�par� les installations (espace � bureaux, mat�riel informatique) et les outils de soutien n�cessaires?

  7. Le suivi et la supervision de projets comprennent la surveillance et l'examen des r�alisations et des r�sultats du projet par rapport aux estimations, aux engagements et aux plans. Ces derniers doivent ensuite �tre modifi�s en fonction des r�sultats obtenus et des r�alisations.

    • Assure-t-on un suivi fr�quent des travaux, des co�ts et du respect du calendrier?
    • Est-ce que la taille des produits est �valu�e p�riodiquement, et les estimations mises � jour en cons�quence?
    • Les activit�s sont-elles r�vis�es et replanifi�es lorsque le projet, tel que r�alis�, diff�re de ce qui avait �t� planifi�?
    • Proc�de-t-on p�riodiquement � des examens de projet internes aupr�s des groupes concern�s afin de suivre les progr�s r�alis�s et de d�celer les probl�mes?
    • Est-ce que des examens sont effectu�s aux points de contr�le importants avec les clients afin d'examiner les r�sultats et les plans ainsi que l'avancement des travaux?
    • Les donn�es estimatives et r�elles portant sur le travail requis, les co�ts et la taille du produit sont-elles consign�es afin d'�tre utilis�es pour la poursuite du projet et dans le cadre de projets futurs?
    • Les probl�mes et les questions techniques sont-ils d�termin�s, document�s et font-ils l'objet d'un suivi (rapports sur les probl�mes, base de donn�es sur les questions techniques, etc.)?

  8. La gestion de la sous-traitance exige la s�lection d'un sous-traitant, l'�tablissement d'engagements avec celui-ci et le suivi et la supervision du rendement et des r�sultats du sous-traitant.

    • Les sous-traitants sont-ils choisis � la suite d'une �valuation de leurs capacit�s?
    • Existe-t-il une proc�dure ou des directives consign�es aux fins de l'�valuation des sous-traitants?
    • Les engagements entre l'entrepreneur principal et le sous-traitant sont-ils �nonc�s dans un contrat?
    • L'entrepreneur principal proc�de-t-il p�riodiquement avec le sous-traitant � des examens techniques de l'�quipement et de l'avancement des travaux?
    • L'entrepreneur principal proc�de-t-il p�riodiquement � des examens de la gestion du sous-traitant pour �valuer les progr�s accomplis et l'�tat de la situation?
    • L'entrepreneur principal proc�de-t-il � un test de r�ception, test qui fait partie des crit�res d'acceptation du produit du sous-traitant?
    • Le rendement du sous-traitant est-il �valu� p�riodiquement, et les r�sultats de cette �valuation font-ils l'objet de discussions avec ce dernier?
    • Les crit�res d'acceptation du produit sont-ils consign�s dans un plan �non�ant le test de r�ception dont auront convenu l'entrepreneur principal et le sous-traitant?

  9. L'assurance-qualit� exige l'examen et la v�rification des produits et des activit�s, afin de s'assurer qu'ils sont conformes aux proc�dures et aux normes pertinentes. Il faut aussi transmettre les conclusions de ces examens et v�rifications aux gestionnaires du projet et autres responsables vis�s.

    • Existe-t-il un plan d'assurance-qualit� pour le projet, comportant des activit�s, des responsabilit�s et un calendrier?
    • Les activit�s d'assurance-qualit� sont-elles men�es conform�ment au plan?
    • Les r�sultats de l'assurance-qualit� sont-ils communiqu�s directement � la haute direction de l'organisation?
    • Les activit�s d'assurance-qualit� et les constatations en la mati�re font-elles l'objet de rapports pr�sent�s p�riodiquement � la direction du projet?
    • Les personnes responsables de l'assurance-qualit� ont-elles une formation dans ce domaine?
    • Les cas d'inobservation qui ne peuvent �tre r�gl�s au niveau du projet sont-ils r�f�r�s � la haute direction?
    • Les responsables de l'assurance-qualit� s'assurent-ils que les activit�s du projet sont conformes au plan du projet et respectent les normes et les proc�dures qui y sont �nonc�es?
    • Les responsables de l'assurance-qualit� v�rifient-ils que les produits sont conformes aux normes, aux proc�dures et aux exigences pr�vues dans le contrat, telles qu'�nonc�es dans le plan du projet ou dans la description des travaux?

  10. La gestion des configurations signifie d�terminer la configuration du produit, soit des produits du travail et leur description, � un moment pr�cis; assurer le contr�le syst�matique des changements apport�s � la configuration et maintenir l'int�grit� et la tra�abilit� de celle-ci au cours du cycle de vie du projet.

    • Existe-t-il un plan de gestion des configurations pour le projet, comportant des activit�s, des responsabilit�s et un calendrier?
    • Les activit�s de gestion des configurations sont-elles conformes au plan?
    • Les produits, les outils et les logiciels ou les proc�dures requis pour r�g�n�rer les produits sont-ils d�termin�s et contr�l�s?
    • Est-ce que le syst�me o� sont conserv�es les donn�es relatives � la gestion des configurations sert de d�p�t pour les �l�ments contr�l�s?
    • Existe-t-il une proc�dure pour extraire des �l�ments du syst�me de d�p�t de gestion des configurations et pour les y reverser?
    • Existe-t-il une proc�dure pour g�n�rer des produits de base � partir du syst�me de d�p�t de gestion des configurations?
    • Dispose-t-on d'information sur le contenu des produits de base et du d�p�t de gestion des configurations aux fins du projet?
    • Existe-t-il une proc�dure ou un m�canisme pour assurer le suivi des changements apport�s aux �l�ments contr�l�s (c.-�-d. une proc�dure de traitement des demandes de changement)?

  11. La focalisation organisationnelle sur les processus visent la conception et le maintien des processus de l'organisation et du projet, ainsi que la coordination des activit�s n�cessaires � l'�valuation, � l'�laboration, au maintien et � l'am�lioration de ces processus.

    • Existe-t-il des activit�s visant � �laborer des processus normalis�s et � am�liorer les processus existants au sein de l'organisation?
    • La responsabilit� relative � l'am�lioration et � l'�laboration des processus se situe-t-elle au niveau de l'organisation plut�t qu'au niveau du projet?
    • Les processus du projet ou de l'organisation sont-ils �valu�s p�riodiquement de mani�re � en �tablir les points forts et les points faibles?
    • Est-ce que l'�valuation des processus d�bouche sur l'�tablissement et l'application de plans d'action?
    • Est-ce que l'organisation dispose d'un plan global d'�laboration et d'am�lioration des processus?
    • Existe-t-il un plan de formation portant sur les processus au sein de l'organisation?
    • La haute direction fournit-elle un appui, des ressources et des fonds suffisants pour assurer l'efficacit� des activit�s d'am�lioration des processus?

  12. La d�finition du processus de l'organisation exige l'�laboration et le maintien des processus normalis�s de l'organisation ainsi que du mat�riel li� aux processus, comme les descriptions des cycles de vie des processus, les directives et les crit�res de personnalisation des processus, la base de donn�es des processus de l'organisation et la biblioth�que de documents sur les processus.

    • L'organisation a-t-elle �tabli et consign� des processus normalis�s (description du cycle de vie des projets)?
    • L'organisation encourage-t-elle l'utilisation de processus normalis�s?
    • Existe-t-il une banque de donn�es de r�f�rence sur les processus (description, directives de personnalisation, normes de codage, proc�dures d'�laboration) qui pourraient �tre facilement adapt�es et utilis�es dans le cadre des projets?
    • Les processus normalis�s sont-ils p�riodiquement r��valu�s et am�lior�s?
    • �value-t-on les technologies, les m�thodologies et les outils nouveaux qui se rapportent aux processus?
    • Les donn�es estimatives et mesur�es sur les processus sont-elles conserv�es dans une base de donn�es afin de servir � am�liorer les processus et � planifier les projets � venir (estimation de la taille du projet, donn�es sur les travaux requis, sur la productivit�, sur les d�fauts)?

  13. Le programme de formation exige d'abord l'�valuation des besoins en formation pour la gestion de l'information et des technologies de l'information, les projets et les particuliers. Il faut ensuite �laborer les cours ou s'en procurer afin de r�pondre aux besoins d�crits.

    • Est-ce que les besoins de formation technique et en gestion sont pr�cis�s pour chaque projet (c.-�-d. nature de la formation, personnes vis�es, moment o� la formation est offerte)?
    • Les personnes qui travaillent � un projet re�oivent-elles la formation jug�e appropri�e?
    • Existe-t-il un plan de formation pour l'organisation, qui �nonce les besoins de formation, les cours offerts, les cr�dits et les ressources disponibles, le calendrier et les normes de pr�paration des cours?
    • Les cours de formation sont-ils pr�par�s � l'interne, conform�ment au plan de formation de l'organisation?
    • La haute direction consacre-t-elle au programme de formation l'appui, les ressources et les fonds suffisants pour en assurer l'efficacit�?
    • Utilise-t-on une m�thode de mesure pour �tablir la qualit� du programme de formation?

  14. La gestion de projets int�gr�e n�cessite l'�laboration d'un processus de gestion �tabli pour le projet et la gestion du projet � l'aide de ce processus. Celui-ci est personnalis� � l'aide du processus normalis� de gestion de projet de l'organisation afin de r�pondre aux caract�ristiques particuli�res du projet (p. ex. PMBOK).

    • Applique-t-on dans le cadre du projet des processus pr�cis qui ont �t� �labor�s � partir des processus organisationnels normalis�s?
    • Les activit�s d�crites dans le plan du projet concordent-elles avec les processus appliqu�s dans le cadre du projet?
    • Utilise-t-on les donn�es recueillies � la suite de projets ant�rieurs (contenues dans la base de donn�es sur les processus de projets de l'organisation) � des fins de planification et d'estimation? (Ces donn�es portent notamment sur la taille des logiciels, les travaux requis, les co�ts, le calendrier, la productivit� et les activit�s.)
    • Le travail accompli, les co�ts et le calendrier sont-ils g�r�s conform�ment � une proc�dure �tablie?
    • Est-ce que la taille du produit fait l'objet d'une gestion conform�ment � une proc�dure �tablie?
    • Est-ce que les risques associ�s au projet sont �tablis, �valu�s, document�s et g�r�s conform�ment � une proc�dure �tablie?

  15. L'ing�nierie de produits logiciels vise l'ex�cution des t�ches de conception n�cessaires � la cr�ation et au maintien des produits, � l'aide des processus de conception �tablis pour le projet, ainsi que des m�thodes et des outils pertinents (p. ex. M�thode 1, DMRPT, etc.).

    • Existe-t-il des outils et des m�canismes efficaces � l'appui des processus logiciels du projet?
    • Existe-t-il une proc�dure �tablie et appliqu�e pour l'utilisation des processus logiciels?
    • Proc�de-t-on � une analyse et � une validation des exigences conform�ment � la proc�dure �tablie pour le projet?
    • Le produit est-il con�u conform�ment � la proc�dure �tablie pour le projet?
    • Le produit est-il mis en application conform�ment � la proc�dure �tablie pour le projet?
    • Les essais ont-ils �t� effectu�s conform�ment � la proc�dure �tablie pour le projet?
    • Les r�sultats d'analyse, de conception, d'application et d'essai sont-ils coh�rents entre eux et concordent-ils avec les besoins du client?
    • Est-ce que les ressources n�cessaires (technologies, comp�tences, mat�riel) sont disponibles?

  16. La coordination intergroupes n�cessite la participation d'autres groupes du projet (sur le plan de l'organisation plut�t que des membres de l'�quipe du projet) notamment des groupes de l'infrastructure, des essais ou de l'assurance-qualit�. Cela permet d'�tudier les besoins, les objectifs et les probl�mes des syst�mes.

    • Les groupes de projet conviennent-ils de leurs engagements, et ceux-ci sont-ils consign�s? (Les engagements peuvent �tre consign�s dans le plan de projet.)
    • Est-ce que des repr�sentants des groupes concern�s participent � la d�finition des exigences du projet et aux n�gociations avec les clients?
    • Existe-t-il une proc�dure pour d�celer les probl�mes intergroupes, en prendre note, en faire le suivi et les r�gler?
    • Les groupes de projet collaborent-ils r�guli�rement en vue de suivre et de coordonner les activit�s de nature technique et de r�gler les probl�mes techniques?
    • Utilise-t-on le plan de projet pour coordonner les activit�s des diff�rents groupes et en assurer le suivi?
    • Les produits transmis � un autre groupe font-ils l'objet d'un examen en vue de s'assurer qu'ils correspondent aux besoins de ce groupe?

  17. Les revues par les pairs comportent une �valuation m�thodique, par les pairs du producteur, des produits pour en rep�rer les lacunes et les aspects � modifier.

    • Les produits font-ils l'objet d'une revue par des pairs? Parmi les produits pouvant faire l'objet d'une telle revue, pensons aux exigences techniques, � l'architecture, aux descriptions de la conception et aux plans d'essai.
    • Les documents devant �tre revus sont-ils remis aux examinateurs suffisamment longtemps avant la rencontre pour qu'ils puissent �tre examin�s?
    • Est-ce que les d�fauts d�cel�s lors de la rencontre d'examen sont consign�s et font l'objet d'un suivi jusqu'� ce qu'ils aient �t� corrig�s?
    • Le plan de projet ou le plan de revue par les pairs �tablit-il quels produits doivent faire l'objet d'une revue par les pairs?
    • Les revues par les pairs sont-ils effectu�s conform�ment � une proc�dure �tablie?
    • L'examinateur utilise-t-il une liste de contr�le �non�ant chaque crit�re � consid�rer pour l'�valuation du produit?