Gestion de projet - Conseils pour vous aider à adopter un processus

Le Rational Unified Process, Enterprise Unified Process, les méthodologies de développement Agile,
Langages de modélisation unifié. Ils viennent dans beaucoup de noms, de la complexité et la taille mais après on va aider à assurer le succès de votre prochain projet.

Cet article n'est pas un aperçu détaillé d'un processus formel. Au contraire, il donne un aperçu des composantes les plus critiques à chaque commune, ainsi que quelques conseils sur les déployer avec succès. Bien que de nombreuses descriptions de processus font un excellent travail de décomposer les différentes composantes du processus, ils couvrent rarement des domaines tels que la façon dont cela affecte votre équipe, combien de processus à utiliser ou d'offrir des conseils pratiques sur les problèmes rencontrés dans le monde réel en essayant de déployer un.

Il peut être très utile, comme l'introduction d'un débutant à traiter et peut vous aider à saisir plus facilement certains des concepts que vous sera présenté. Pour le gourou processus plus expérimentés qu'elle aurait quelques conseils utiles sur le lissage sur une partie des bords rugueux nous traitent tous de temps à autre.

L'information est ici basé sur les expériences et les leçons apprises dans plus de 15 années de développement et la gestion de plus de 100 communiqués de projet complexe.

Suite à ces principes de base permettra d'améliorer vos chances de succès dans tout processus que vous adoptez et fournir une base solide pour qu'il maturation.

Qu'est-ce qu'un processus et pourquoi ai-je besoin?

Indépendamment de ce que nous sommes en affaires, les logiciels, conception de site Web ou au détail de vêtements, nous avons tous un processus que nous suivons pour compléter un projet donné. Parfois ça marche et parfois pas, avec des résultats souvent coûteux. Lorsque nous parlons de l'adoption d'un processus que nous parlons d'un processus plus formel. Un processus est essentiellement un ensemble intégré de rôles, les méthodes et techniques dans la partie, aider à atteindre les objectifs suivants:

     * Minimiser les risques.
     * Plus d'estimer avec précision votre calendrier du projet et le budget.
     * Détecter des problèmes au début (en amont) au lieu de plus tard (en aval) quand ils sont beaucoup plus coûteux à corriger, si elles peuvent être fixées à tous.
     * Une meilleure communication entre les membres de l'équipe en ce qui concerne la portée du projet, les exigences et le statut.
     * Plus de suivre avec précision l'état d'avancement du projet et de détecter le glissement rapide.
     * Réaliser les objectifs du projet de manière aussi efficace et rentable que possible.

Des processus formels sont souvent créés et affiné au cours des essais et erreurs pour tenter de créer un idéal «recette» pour avoir une chance optimale à mener à bien tout projet. Alors qu'ils ont été développés et utilisés dans le développement logiciel, de l'aérospatiale et l'ingénierie, la plupart des concepts de base ne sont pas spécifiques à ces derniers ou toute industrie et tout le monde peut bénéficier de leur utilisation.

Combien de processus est-elle suffisante?
Il est essentiel à la réussite de tout processus visant à comprendre à quel point vous avez initialement besoin de mordre. Le risque d'essayer de faire trop et trop vite à un processus peuvent être aussi risquées que ne rien faire du tout, surtout si vous êtes une entreprise plus agile essayant de faire la transition à être plus axés sur le processus. Surcharge de votre équipe avec un nouvel ensemble de responsabilités et les méthodes qu'ils ne sont pas habitués à destination ou en prêt pour peut facilement vous faire dérailler. Toutefois, si vous n'avez pas commencer à changer, vous continuerez à avoir les mêmes problèmes. Voici quelques conseils de trouver le juste équilibre.

     Facteur de risque *. Qu'est-ce facteur de risque du projet? Évidemment faire du logiciel pour un coeur artificiel est beaucoup plus risqué que de déployer la troisième génération d'un site web et le processus, d'abord de toute façon, doit correspondre au risque. Le premier aurait besoin vaste, redondante et exhaustive les contrôles qualité et des soldes lorsque celui-ci peut être facilement ajustée à la volée après le déploiement sans aucune perte de vie. Soyez réaliste quant à ce que vos risques sont, comment elles seront coûteuses pour traiter en aval, et l'utiliser comme une base pour décider combien est nécessaire. Personne ne connaît votre environnement, projet et une équipe mieux que vous, alors user de bon sens pour décider ce qui se sent bien.


     * Combien pouvez gérer votre équipe et qu'est-ce que le plus besoin? L'impact sur l'équipe est souvent négligé. Tout processus est seulement aussi bon que ce que votre équipe peut gérer et peu importe les avantages ultimes, d'abord une cause effort supplémentaire en matière de formation et les nouvelles tâches de votre équipe n'est pas habitués à gérer. Pour réussir, vous devez obtenir l'adhésion et un engagement envers le processus de tout le monde. Si vous n'avez pas votre équipe ira tout simplement par les mouvements et roulent des yeux collective aux réunions de projet. Pour surmonter cette trouver leurs points de douleur dans la façon dont ils travaillent maintenant et commencer par les domaines du processus qui traitent directement de ces.


     * Commencez petit. Commencez par un petit nombre de domaines que vous jugez essentiels, y compris les points à nouveau la douleur que votre équipe voit des avantages immédiats. Il sera plus facile d'ajouter des couches processus plus tard quand ils le voient comme un avantage et non pas simplement des couches supplémentaires de bureaucratie. Remporter l'adhésion en est critique et si vous commencez petit votre équipe aura une chance d'obtenir leurs têtes collective autour de ce ainsi que voir les avantages, ce qui rend plus facile la maturation aval.


Équipe et de l'environnement

Un des éléments les plus souvent tendance à négliger d'employer ou de maturation d'un processus, c'est l'équipe elle-même. Chaque équipe a une dynamique différente et réagissent très différemment à divers aspects de ce que vous essayez de le faire. Trop souvent, de la frustration des problèmes nouveau processus est forcé sur une équipe. Cela ne signifie pas que votre équipe doit dicter votre processus, mais comme mentionné ci-dessus vous pouvez acheter votre équipe pour ce que vous faites est essentiel pour votre succès. Je n'ai jamais vu un processus avec succès écrasé sur une équipe. Donc, avancer avec précaution, demandez à votre équipe impliquée dans les discussions sur ce que vous faites et pourquoi, il paiera des dividendes.

     * Rôles et responsabilités. Tout processus auront des rôles définis pour chaque individu et il est essentiel que chaque personne comprenne clairement le rôle qu'ils vont jouer et se sentent à l'aise dans ce rôle. Passez un peu de temps ici et demandez aux gens s'ils sont à l'aise dans leur rôle, poser des questions et écoutez! Une fois que votre équipe est fixé, assurez-vous qu'ils sont habilités à faire ce qu'ils doivent faire et s'assurer que chacun dans l'équipe est au courant de qui a un fusil et un badge. Si vos développeurs refusent de dire à votre chef de projet les renseignements dont ils ont besoin, vous aurez un problème. Si le gestionnaire de projet réagit en supprimant des étapes douce dans votre plan de projet que vous avez un problème, vous ne saurez même pas sur qu'il soit trop tard. Donc, s'assurer que les rôles sont clairement définis pour tous et que tout le monde sait qui a le pouvoir de l'équipe.


     * Divulgation complète. Assez ne peut pas être dit à ce sujet. Le but de tout processus est de résoudre les problèmes le plus tôt (à un prix avantageux) que possible et cela ne peut être fait avec une visibilité à tous les stades d'évaluer avec précision l'état du projet. egos développeurs, des luttes intestines de l'équipe et position défensive tout créer un environnement où aucun processus ne peut être efficace. Il est essentiel que les membres de l'équipe sont prêts à admettre ses erreurs, appeler les problèmes et faire d'une manière qui ne crée pas un environnement hostile. Pour ce faire vous devez réunir les parties et de discuter ouvertement de cette question. Adresse du fait que des questions sont soulevées pour le bien général du projet et l'organisation. Récompenser ceux qui trouvent à redire en eux-mêmes et de signaler les erreurs. Souvent, la tension peut être effacée en commençant par reconnaître vos propres erreurs d'abord, d'autres suivront, afin de montrer l'exemple et vous verrez que vous pouvez créer un environnement ouvert ont été les gens se sentent libres pour afficher des erreurs et même des critiques de manière constructive.


     * Visibilité. Similaires à ce qui précède, la visibilité est tous les gens de se sentir à l'aise de divulguer des informations au groupe. Les développeurs veulent s'asseoir sur le code jusqu'à la dernière minute parce qu'ils savent qu'il n'est pas prêt, les concepteurs de la haine de voir des gens œuvre inachevée. Donc, comprendre pourquoi votre développeur ou concepteur peut être secousses que leurs premiers travaux est défilé devant un groupe et de la bande de roulement légèrement d'abord à la critique jusqu'à ce qu'ils deviennent plus à l'aise avec cela. Des expressions comme: "C'est vraiment super, mais que diriez-vous ..." sont inestimables, les utiliser! L'objectif fondamental de tout processus de capture est bonne questions aussi tôt dans le processus que possible. Donc, vous devez en discuter avec votre équipe et s'assurer que chacun comprend que cela ne peut être fait avec une visibilité totale sur tous les aspects du projet.


Les outils appropriés

Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer. Donc, assurez-vous que vous avez les bons outils en place pour les gérer le processus et être capable de suivre et de communiquer sur votre projet.

     * Gérer le processus. Il ya beaucoup d'excellents outils disponibles pour gérer les exigences, l'assurance qualité, et le développement. Comme dans le processus lui-même effectuer un appel sur combien vous avez besoin avant de vous lancer et commencer à acheter. Côte-des pièces jusqu'à critiques du processus. La gestion des exigences est souvent le plus d'attention, mais les exigences peuvent être facilement gérés dans un document Word tout en AQ est souvent négligé. Une base de données solide qui permet d'AQ pour suivre la mise en œuvre de fonctions jusqu'à la fin et tous les bogues qui résultent seront précieuses pour l'AQ et le développement et le projet dans son ensemble.


     * Suivi du projet. Il est essentiel que votre chef de projet est armé d'un outil qui peut être utilisé pour montrer l'avancement du projet et ses divers commentaires. Rechercher des outils qui permettent le bon niveau de détail (de haut niveau pour la gestion) et plus détaillée des différents départements et le chef de projet eux-mêmes. Par exemple Microsoft Project [http://office.microsoft.com/en-us/project/default.aspx/] par exemple est un excellent outil de gestion des règles très strictes projets portés. Cependant de nombreux projets sont entraînés exception, ce qui stricte des outils de gestion de projet difficile à utiliser dans un environnement fluide en évolution. Une bonne alternative est un logiciel de planification civile comme le planificateur de calendrier qui prévoit la possibilité de gérer différents niveaux de détail dans un format facile à utiliser civile. Permettre l'état du projet pour être facilement communiquées sein de l'équipe.


Champ d'application

Suivant l'environnement de l'équipe c'est sans doute l'aspect le plus critique de tout projet. Il faut absolument mettre l'accent sur la portée de définir clairement dès les premiers stades de développement. La plus grande erreur est généralement essayer d'en faire trop sur trop peu de calendrier ou de budget ou de définir le champ d'application et puis ne pas y adhérer. Cette frustre les développeurs et les jette en fin de compte le projet dans le chaos.

     * Soyez réaliste. Tout le monde veut tout droit maintenant, en particulier des ventes et du marketing. Posez des questions difficiles au début de ces départements sur les fonctionnalités de vos clients DOIVENT avoir par rapport à ce qu'ils veulent avoir. Parfois, vous trouverez les marketeurs ont fait des promesses à un seul client et tentent de sauver la face quand dans le grand schéma de la fonction n'est pas aussi importante aux objectifs de l'entreprise. Concentrez-vous sur ce que vous vraiment devez faire, leur faire savoir qu'ils ne peuvent pas tout avoir et les obliger à choisir. Assurez-vous que les objectifs de l'entreprise sont représentés en tout temps dans les exigences. C'est là que le document Vision vient ci-dessous en


     * Document Vision. Ceux-ci peuvent avoir des noms différents pour des méthodes différentes mais un document de vision est essentiellement un aperçu de haut niveau de votre projet. Pensez-y comme un énoncé de mission pour le projet lui-même. C'est là que l'entreprise peut définir clairement quels sont les objectifs du projet. Qui sont les parties prenantes et quelles sont les exigences de haut niveau sont. Ce sera votre document principal pour définir la portée du projet. Gardez-le de haut niveau, les détails peuvent venir d'ailleurs. Assurez-vous que les exigences carte pour les buts et que vous aller de l'avant le travail effectué reste fidèle à ces objectifs et exigences. Cela peut changer, mais seulement lorsque les parties prenantes s'accordent et signent sur les changements.


     * Ne pas augmenter la portée, sans réglage de votre calendrier et le budget! Il semble assez simple, mais sans doute l'erreur la plus courante. Les gens ont toujours essayer d'ajouter "petites" choses qui impliquent «un minimum d'effort". Ces s'additionnent et l'impact n'est pas souvent abordé, ce qui conduit finalement à une défaillance de calendrier et le budget. Le conseil changement est votre principal moyen de défense contre ce, voir tableau ci-dessous le changement.


Exigences

Exigences de tout projet sont délicates et de nombreux excellents livres sont dédiés à ce seul sujet. Il est vrai que des projets qui échouent la plupart des questions on peut faire remonter les besoins. Étrange de voir comment cela continue d'être le cas lorsque les besoins sont le moyen le plus simple et le moins cher pour trouver et résoudre les problèmes.

     * Un problème ne sera jamais moins cher qu'il ne l'est en ce moment. Lorsque vous passez en revue vos besoins, vous avez besoin pour vraiment donner votre avis, ne se contentent pas de les numériser. Réfléchissez et essayez de visualiser ce qu'ils disent. Vous trouverez souvent des problèmes sont apparents à la surface. Prenez le temps de faire des examens sérieux et continuer à affiner les besoins jusqu'à ce que tout le monde se sent qu'ils sont corrects. Comparer les frais de ré-écriture d'une phrase dans un traitement de texte à des centaines ré-écriture de lignes de code, re-tester et re-déploiement et vous verrez ce sont les dernières chances que vous avez à une solution bon marché.


     * Obtenez vos clients concernés, au début! S'assurer que les clients sont impliqués dans les premières étapes d'exigences et de maintenir leur participation. Souvent, un des développeurs du client quelque chose de demandes et puis disparaissent à comprendre. Grosse erreur! Revenez à vos clients avec des explications sur la façon dont vous envisagez la maquette fonctionnalité et l'utilisation autant que possible afin qu'ils puissent le visualiser. Vous trouverez que faire même un simple dessin de quelque chose non seulement permettre au client de saisir plus facilement, mais vous permet de repérer rapidement les problèmes que vous n'avez pas pris en considération.


     * QA commence à exigences. AQ devraient être impliqués dès le début non seulement la fin du projet comme c'est souvent le cas. Qu'ils librement examiner les documents et les exigences Vision. Ils considèrent souvent les problèmes potentiels que les autres ministères peuvent manquer.


Conseils changement

Quand cela est fait correctement changement conseils peuvent presque à lui seul de gérer les projets les plus difficiles. Toutefois, si vous n'avez pas l'environnement d'équipe correcte en place tel que mentionné ci-dessus, ils seront au mieux inefficace, au pire va créer plus d'animosité.

     * Qu'est ce que c'est. Très simplement le conseil changement est une réunion où chacun des ministères clés et parfois les clients sont représentés et ont l'occasion de discuter du projet sous tous les angles. L'idée est de s'assurer que chacun est conscient de l'état et est capable de parler de l'impact de tout changement dans les besoins ou le calendrier aura sur leur ministère respectif.


     * Qui est là? En général, la liste comprend les éléments suivants: marketing, ventes, assurance de la qualité, opérations, développement, informatique, gestion de projet, les clients. Essentiellement tous ceux qui ont un intérêt dans ou est touchée par le projet. Selon la nature du projet Marketing ou ventes représentent souvent le client. La règle la plus importante est ici, si quelqu'un est identifié comme une partie prenante dans le projet, n'ont pas une réunion sans eux. S'ils ne peuvent pas être là, de reprogrammer.


     * Par où commencer? Une excellente façon de commencer est généralement d'avoir tout le monde fournir une brève mise à jour sur ce qu'ils font sur le projet. Ceci aide à enlever les coins sombres, rappelle souvent les zones de déconnecter et aide à soulager la tension de ces réunions parfois les plus controversées en donnant à chacun un sujet facile à couvrir et peut-être se vanter un peu pour commencer.


     * Où se concentrer? La question clé au début des réunions du conseil le changement est possible. Ce qui est et ce qui est out? Ce sera une attraction et de répulsion entre ce que ventes et du marketing veulent et ce que les responsables de la prestation peut gérer. Après le champ d'application s'installe, il est sur le statut. Les exigences toujours correctes? Les priorités ont ajusté? Sommes-nous sur la bonne voie? Le plus important chaque groupe est représenté si Marketing dit: «Je dois avoir ça", le développement est là pour parler de l'impact de cette situation sur le calendrier, en temps réel. Là encore, il favorise la visibilité et rend les choses d'être modifiée sans que chacun d'être en mesure de parler aux ramifications. Il contrôle et informe en même temps.


     * Combien de fois? Ils sont très utiles afin de les faire aussi souvent que vous avez besoin. Cela dépendra de la nature du projet, mais tous les 1-2 semaines est la meilleure. Plus et vous commencez à avoir une communication trop peu et trop nombreux domaines potentiels de dérapage, pas plus fréquentes et vous mangez dans le temps trop de travail.


     * A ne pas faire. Ne laissez pas la réunion de descendre dans les arguments et les pointer du doigt. Le conseil changement est un outil qui sert tous les ministères. Il est essentiel qu'elle demeure un endroit où les gens peuvent parler ouvertement de questions. Il ya une place pour la réalité, pas de spin. Ce sera plus difficile que cela puisse paraître par moments, mais résister à la tentation de les éviter. Il n'ya pas de réunion plus importante à la réussite d'un projet que ces derniers.


Post Mortem

Le post mortem est une réunion de se réunir une fois le projet achevé. Ce n'est pas un parti après la libération, bien que selon le succès qu'elle peut avoir cette atmosphère. C'est une chance pour certains franc-parler sur ce qui s'est passé et surtout comment en parler dans l'avenir. Tout le monde lignes pour Post mortem quand les choses allaient bien, mais vous pouvez en savoir plus auprès de vous d'échecs que de vos succès. Donc, si vous avez eu beaucoup de problèmes, ne manquez pas cette occasion pour y faire face quand elles sont encore fraîches dans l'esprit de tout le monde! En outre, les équipes ont besoin d'un sens de fermeture et cela les aide à le faire ainsi que de ventilation de sorte que vous pouvez effacer l'air avant de commence prochain projet.

     * Laissez votre ego à la porte. N où sont le franc-parler et la capacité de fournir et accepter les critiques constructives plus critique. Cette réunion ne peut pas être sur ego, ou l'ACY, il a, dans une discussion franche sur les erreurs commises par tout le monde (nous en faisons tous) ou les régions dans le processus qui doivent être améliorés. Encore une fois pour donner le ton essayer menant à la réunion par la personne la plus haute dans la salle de discussion erreurs qu'ils ont faites ou des choses qu'ils ont appris. Il aide vraiment le ton juste et apaiser les tensions.


     * Prendre des notes, puis l'action. C'est le temps d'apprendre et trop souvent, les gens de discuter des questions puis s'éteint et ne rien faire. C'est l'occasion de prendre des mesures correctives pour vous faire économiser temps et argent sur le prochain projet. Alors, prenez des notes et de les mettre en action le fer pendant qu'il est chaud.

Suivez ces étapes dans un processus que vous adoptez ou tout autre projet que vous gérez et vous devriez trouver il va vraiment améliorer vos chances de succès.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?Project-Management---Tips-For-Helping-You-Adopt-A-Process&id=487839