Mesures clés de succès l'intégration de systèmes de gestion de projet

Avez-vous déjà voulu une courte liste de d'objets, de tenir "en échec" comme vous gérez les projets? Cette courte liste devrait contenir des mesures clés qui, si toujours tenu en échec et d'équilibre, vous conduiraient à la réussite du projet? Bien sûr, il est important de suivre les lignes directrices du projet de l'industrie de l'Institut de gestion de projet et au sein du Project Management Professional (PMP) la certification, mais il est important de toujours garder ces mesures clés à la pointe de mon esprit ALL THE WAY à travers le projet - à partir de début d'achèvement. Parfois, ces facteurs peuvent être négligées ou oubliées, ou considérés comme "non nécessaires" dans la course pour obtenir un cours de projet. Stand Up et d'arrêter la folie, assurez vous d'avoir une voie claire avant d'essayer d'arriver à votre destination .... Ou vous allez vous perdre en chemin.

Mesures clés:

Avant même regarder besoins de l'entreprise ou de dépenser beaucoup de temps sur un projet, assurez-vous de savoir qui est le commanditaire de direction est et obtenir les informations suivantes directement de ce sponsor:

i. Projet intentions et la portée
II. Ce que le projet n'est pas ou ce qui est hors de portée
III. Qui sont les "clients" sont pour le projet. (plusieurs fois, les clients sont internes à l'organisation)
IV. Si un retour sur le document d'investissement a été créé et ce qui est attendu d'un document de retour sur investissement. Quels sont les domaines de l'entreprise retours sont attendus?
c. Budget du projet et la façon dont les dépenses sont approuvées
VI. Attendus du projet Facteurs de réussite
VII. Qu'ils veulent que ce projet va de l'avant à l'heure actuelle, sinon, quand est-il de commencer à
VIII. Chronologie prévus pour l'achèvement du projet
IX. Accord visant à mettre les ressources des entreprises sur le projet pour l'obtenir fait
x. Requis état du projet et de rapports
XI. Accord sur un plan de communication pour les sponsors, clients et autres parties touchées
XII. Accord sur le gestionnaire de projet désigné et le soutien du parrain que si il ya des problèmes avec le projet qui nécessiterait l'attention sponsors exécutif, que le promoteur va étendre son soutien pour l'obtention de la résolution

Ensuite, mettre toutes ces informations par écrit, généralement dans une sorte de document de lancement du projet, puis tous les chefs de projet, les promoteurs et les clients et CIO signer le document. Je ne peux pas souligner l'importance de cette partie est. Je n'insisterai jamais combien de fois nous sommes arrivés à la fin d'un projet et au moins un de ces partis (sponsors, clients ou CIO) indique qu'ils n'ont jamais entendus sur certaines partie de l'information documentée dans le document de lancement du projet. Cela est particulièrement important pour les projets de mise en œuvre du système que beaucoup de temps peut s'écouler entre le moment où le projet a démarré et le moment où le produit final soit livré.
Business Requirements

Il est extrêmement important, avant de parler avec tout le personnel des TI (si le projet implique IT interne - qui, si elle est mise en œuvre du système, il sera plus probable) ou les vendeurs de produits, que vous preniez le temps nécessaire pour documenter adéquatement tous les besoins de tous clients. Documenter les besoins de l'entreprise devrait, au minimum, impliquent en passant par les étapes suivantes:
Identifier les experts en la matière et des représentants de projet de chaque partie de l'entreprise qui servent de vos clients pour le résultat final du projet.

Identifier le problème actuel ou besoin
Documenter les processus en cours
Discutez de ce qui ne fonctionne pas sur le processus
Examinez les résultats qu'ils aimeraient voir pour soutenir les activités et l'analyse dont ils ont besoin pour effectuer de gérer l'entreprise

Dans la documentation Business Requirements, NE PAS passer du temps à discuter de ce systèmes ou de technologies permettra à les faire. Discutez de ce qui est nécessaire pour l'entreprise. Ne laissez pas vos clients d'essayer de définir un processus autour de systèmes ou de technologies. La technologie est là pour soutenir l'entreprise, pas de dicter comment une entreprise doit être exécutée. Ne vous inquiétez pas, toutes les pièces techniques se réuniront plus tard.
Documenter tous les besoins de l'entreprise tel que discuté avec tous les groupes de clients et experts en la matière. Assurez-vous de préciser les problèmes et les besoins, comment il nuit à l'entreprise, ce qui est nécessaire, et comment cela va aider l'entreprise. Soyez précis. Cette information vous aidera à mettre ensemble le document de retour sur investissement pour s'assurer que le coût et les bénéfices attendus sont en ligne avec ce que le promoteur du projet (s) attend. Certains directeurs de projet peuvent être en désaccord ici et dire que le retour sur investissement doit être fait avant d'arriver à la phase de développement exigences. Cependant, j'ai toujours trouvé de nouveaux domaines d'investissement (coût) et le retour sur investissement se présentent lors du passage à travers le processus besoins de l'entreprise de découverte.
Assurez-vous toujours de penser à la façon dont un produit sera utilisé et la façon dont les rapports seront nécessaires. Cela peut vraiment vous obtenez à la fin, si vous ne payez pas une attention particulière à l'avance pendant la phase de gestion des exigences.
Vous serez alors correspondre aux besoins de l'entreprise à la portée que vous avez créé dans le document de lancement du projet, ou de modifier la portée, qui exigerait un amendement au document de projet nécessitant l'initiation de nouvelles signatures.
Une fois le bon ensemble d'exigences est documenté et qu'il s'aligne avec la portée du projet, alors assurez-vous d'avoir à nouveau les promoteurs du projet, les clients (rappelez-vous, le client peut être interne ou externe), et le CIO en reconnaissant ce sont les besoins de l'entreprise, que le projet est active et commerciaux, et qu'ils sont en accord avec de nouvelles avancées aux prochaines phases du projet. Cette pièce est particulièrement important, car les gens ont tendance à oublier ou à dire des choses comme «Je n'ai jamais dit que« comme vous obtenez plus loin dans le projet. Vous pouvez toujours les ramener à la documentation initiale et de signatures. Si vous n'obtenez pas les signatures, vous êtes un canard de séance.

Maintenant il est temps de décider comment vous allez remettre sur ces besoins fonctionnels. Cela conduit généralement à une acquisition ou la construction décision. Voilà, vous pouvez acheter un logiciel d'un fournisseur qui se spécialise dans le type de produit nécessaire, ou construire avec le personnel informatique interne. Les exigences opérationnelles document est votre base pour évaluer les acheter ou construire décision. Ne vous éloignez pas, ne s'étend pas portée ou de budget, sans repasser par le signe-off processus. Si vous êtes à "acheter" un produit provenant d'un vendeur, ne l'initiale «éplucher le bas» de la détermination de produits logiciels dessus qui correspond aux besoins d'affaires.
Maintenant que vous avez votre tête de liste des prétendants au logiciel, sont des démonstrations effectuées par les vendeurs pour votre groupe client (s). Ils peuvent aider le vote pour le produit sélectionné. Il est essentiel d'obtenir l'adhésion de vos clients à chaque étape du chemin.
Si possible, il est une bonne idée d'effectuer un essai de phase avec 2 vendeurs en haut pour voir comment les besoins de l'entreprise correspondent au produit.
Après la phase d'essai, revenez avec vos clients afin de démontrer les produits contre les exigences du marché. Alors que vos clients à faire leur sélection finale. À ce stade, être sûr qu'un document de spécifications techniques est écrit que les matches contre les exigences des entreprises. L'objectif du document de spécification technique est de démontrer dans le produit, comment les exigences opérationnelles soient respectées, quelles sont les exigences des entreprises ne peuvent pas être respectées, ou ne peut être satisfaite en partie et les besoins en TI pour le produit. Assurez-vous que, avant d'amorcer une phase de développement importante, que vous avez retourné à vos sponsors, clients et CIO ou un autre représentant de TI parties à un accord sur le cahier des charges et l'accord pour aller de l'avant. Cette phase nécessitera aussi un calendrier de mise à jour de projet décrivant le calendrier de développement intégral, les ressources nécessaires, et l'engagement des parties concernées.
Soyez sûr de faire une vérification d'impulsion "avec vos clients et les commanditaires à de nombreux points tout au long du cycle de développement. Ceci assurera à vos clients ne sont pas surpris par le résultat final ou que vous n'avez pas complètement disparu dans une voie qu'ils ne voulaient pas ou que vous avez développé quelque chose de manière incorrecte. Il est beaucoup mieux attraper ces choses tandis que le développement est toujours en cours - votre temps en ligne sera probablement un impact beaucoup moins de cette manière et la perception de la réussite du projet par les clients et les sponsors seront beaucoup plus élevés de cette façon. En fin de compte, il est préférable de ne pas avoir de tels "hang-ups" pendant le processus de développement. Mais, il n'est probablement pas réaliste de s'attendre à ce que vous ne serez pas en avoir. C'est le travail du gestionnaire de projet - pour travailler à travers ces questions et encore achever le projet à temps.
Lorsque la phase de développement est terminé, il est important que vous avez documenté non seulement comment utiliser le produit, mais comment elle influence les processus d'entreprise. Il faudra discuter avec les représentants des groupes des internautes sur ce que le système va maintenant faire et ce que le nouveau processus devrait ressembler. Il est important d'avoir ce document et être en accord avec les représentants des internautes groupe avant d'lancement du produit a lieu. Si vous faites cela, vous pouvez vous attendre à une formation beaucoup plus lisse et la phase de lancement de ce produit que si vous essayez juste de jeter le produit là-bas. Si vous n'avez pas une formation planifiée avec soin et de la phase de déploiement, tout le travail ira dans les égouts, et le projet sera très probablement pas être perçu comme un grand succès.
Au cours de la phase de déploiement et de formation, il est extrêmement important de communiquer ce que les utilisateurs doivent faire s'ils ont besoin d'aide avec le produit. Quel soutien pour le produit est disponible? Un chef de projet aura déjà bien présent en place et être prêt à mettre le processus de soutien en mouvement pendant la phase de déploiement et de formation. Il est également important que vous obteniez l'accord de la clientèle de groupe sur le processus de soutien et qu'ils pensent qu'il fonctionnera pour leur groupe.
Enfin, assurez-vous de suivi avec les groupes de clients que les choses soient le bon fonctionnement et de voir quels problèmes ou questions devront être corrigées. Garder le faire jusqu'à ce que vos clients sont satisfaits avec le produit.

Rappelez-vous, il n'ya pas de taux de réussite. Soit il fut un grand succès, ou qu'elle n'est pas. Date de l'article: Date: 30-Jun-2006