Partager via

Début d'un projet

  • Article

Vous organisez les ressources de base du projet au cours d'une étape initiale intitulée Début du projet.

Dans cette rubrique

  • Réunion de planification

  • Développement itératif

  • S'agit-il d'un projet reposant sur une portée ou sur une date ?

  • Planifier les ressources de projet

  • Définir les rôles et responsabilités

  • Définir un plan de communication

  • Identifier les parties prenantes

  • Tracer le plan de projet

  • Réviser le plan de projet

  • Obtenir des engagements de projet

Réunion de planification

Au début du projet, plusieurs parties prenantes et experts techniques doivent se réunir pour discuter du projet et créer le plan de produit. Vous devez choisir ces parties prenantes en fonction de la nature et de la complexité du projet et des éléments à livrer.

En fonction de la taille du projet et de sa complexité, la réunion peut porter sur plusieurs jours ou semaines.

Développement itératif

Une technique importante de la gestion des risques est la planification de votre projet en itérations, qui durent en général entre quatre et six semaines. Un plan d'itération est une liste de fonctionnalités que l'équipe de projet va développer et tester. Chaque fonctionnalité spécifie une tâche ou une variante améliorée d'une tâche que l'utilisateur sera en mesure d'effectuer à l'aide du produit. À la fin de chaque itération, les fonctionnalités planifiées font l'objet d'une démonstration. À la fin de certaines itérations, le produit en partie terminé est diffusé pour évaluation par un nombre limité d'utilisateurs.

Les commentaires découlant de ces démonstrations et évaluations sont utilisés pour réviser le plan.

Le plan de produit est organisé de telle façon que les principaux scénarios utilisateur et les principaux composants du système soient mis en œuvre lors des premières étapes, même s'il s'agit simplement d'une forme simplifiée.

L'un des risques les plus significatifs de la plupart des projets est la mauvaise compréhension des spécifications. Les spécifications peuvent être mal comprises non seulement par l'équipe de développement, mais également par les utilisateurs finaux et les parties prenantes. Ceux-ci peuvent avoir du mal à imaginer comment leurs activités professionnelles seront affectées par l'installation du nouveau système.

De plus, le contexte métier peut changer pendant le déroulement du projet, ce qui entraîne une modification des spécifications du produit.

Un processus itératif fournit l'assurance que tout ajustement des spécifications requis suite à la démonstration du produit peut être effectué avant la fin du projet, sans entraîner les coûts liés à un changement important dans le travail.

Un autre risque significatif est la mauvaise estimation des coûts de développement. Il peut être difficile pour les développeurs qui travaillent dans un nouveau domaine, et parfois sur une nouvelle plateforme, d'estimer exactement les coûts de développement avant même le début du projet. Dans certains cas, il peut être difficile de déterminer si une stratégie d'implémentation particulière sera assez efficace. Cependant, en révisant le plan à la fin de chaque itération, l'équipe peut prendre en compte l'expérience des itérations précédentes. C'est l'une des raisons pour lesquelles un bon plan de produit planifie une partie du travail sur chaque composant principal dès les premières itérations.

S'agit-il d'un projet reposant sur une portée ou sur une date ?

Certains projets exigent que toutes les spécifications soient fonctionnelles avant la remise du produit. Ces genres de projets sont exceptionnels dans un contexte de logiciel. Un exemple réel peut être la construction d'un pont. Une travée à moitié terminée ne sert à rien. En revanche, un projet de logiciel à moitié terminé mais correctement planifié doit être déployable et utilisable par un nombre limité d'utilisateurs. Il peut ensuite être complété petit à petit lors de plusieurs mises à niveau.

Déterminez tout d'abord si votre projet repose véritablement sur la portée. Dans ce cas, pour déterminer une date de fin, vous devez attendre de disposer d'un plan et d'estimations détaillés. Ceci a un prix. Le travail de planification est augmenté et le non-respect du calendrier suite à de mauvaises estimations entraîne le retardement de la date de remise du produit, ce qui augmente les coûts. Par conséquent, avant de décider que votre projet repose sur la portée, assurez-vous-en absolument. Ceci est plus probable dans un environnement d'ingénierie de systèmes complexe que dans une situation de service ou de produit logiciel.

La plupart des projets logiciels reposent sur la date car ils peuvent être fournis de façon incrémentielle. Par exemple, si un jeu sur ordinateur doit sortir pour les fêtes de fin d'années aux États-Unis, il doit être prêt en octobre. S'il n'est pas prêt en octobre, les ventes entre Halloween et Noël en sont affectées et si le calendrier a plus de deux mois de retard, toutes les opportunités de vente peuvent être perdues.

Planifier les ressources de projet

Un projet doit disposer de tout le personnel nécessaire pour être terminé à la date souhaitée. Les données d'historique de projets précédents doivent être utilisées pour organiser la discussion relative aux ressources requises.

Une fois que vous avez défini vos besoins en personnel, créez un organigramme de projet qui identifie clairement la structure de l'équipe de projet, les niveaux de ressources et la répartition géographique, le cas échéant. Enregistrez toutes les informations de personnel dans votre portail de projet.

Définir les rôles et responsabilités

Décrivez chaque rôle de projet et ses responsabilités, et publiez-les dans le plan de projet. Chaque personne qui rejoint le projet doit comprendre son rôle et ses responsabilités dans le cadre de ce projet.

Définir un plan de communication

Il est important de définir un plan de communication pour le projet. Les voies de communication facilitent la gestion des coûts de coordination du projet. Il est important d'indiquer qui doit assister aux réunions, à quelle fréquence les réunions sont organisées, les voies de communication et comment transmettre les problèmes qui ne peuvent pas être résolus par les participants habituels d'une réunion.

L'objectif d'un bon plan de communication est de s'assurer que les activités de coordination du projet se déroulent le mieux possible et d'éviter de mettre en œuvre des efforts inutiles en raison d'une mauvaise communication.

Le plan de communication doit être publié sur le portail du projet et faire l'objet de la maintenance requise. Un plan de communication est un outil utile pour tout le personnel, en particulier les nouveaux membres. Il les aide à comprendre le fonctionnement d'une plus grande équipe et comment travailler en communiquant de manière appropriée de différentes façons, avec différents membres de l'équipe et dans des objectifs différents.

Identifier les parties prenantes

Identifiez toutes les parties prenantes appropriées pour le projet. En plus des principaux membres de l'équipe, cette liste doit inclure les dirigeants et le personnel technique qui ont un intérêt dans l'implémentation réussie du projet ou dans l'effet que le produit peut avoir après sa mise en service. Ces parties prenantes peuvent figurer en amont ou en aval de l'activité de génie logiciel.

Tracer le plan de projet

Créez une ébauche du premier plan de projet, qui peut être révisée au début du développement. L'objectif de cette ébauche est de faciliter les discussions relatives aux ressources et à la chronologie du projet avec les commanditaires. Elle doit présenter les principales fonctionnalités et la date estimée de leur livraison. Pour plus d'informations, consultez Planification du projet (CMMI).

Réviser le plan de projet

Publiez le plan de projet sur le portail du projet. Bien que le plan présente déjà beaucoup de travail, il s'agit quand même d'un plan de niveau supérieur qui remet à plus tard de nombreuses décisions de planification détaillées. Ceci est intentionnel. Trop de détails à ce moment entraîne un gaspillage ultérieur.

Lorsque les spécifications sont incertaines, planifiez-les uniquement dans le plan et différez-en les détails jusqu'à ce que vous disposiez de plus d'informations. Prévoyez d'obtenir ces informations.

Planifiez une réunion de révision avec toutes les parties prenantes. Les réunions en face à face sont toujours mieux adaptées pour ce genre d'activité. Veillez à prévoir assez de temps pour permettre une révision complète et autoriser l'expression d'opinions dissidentes.

Obtenir des engagements de projet

Maintenant que le plan de projet fait l'objet d'un accord avec les parties prenantes, obtenez des engagements de la part de chaque partie prenante pour l'approbation du plan de projet.

Recueillez ces engagements et archivez-les dans le portail du projet.

Ressources supplémentaires

Pour plus d'informations, consultez les ressources Web suivantes :