Création de la portée du projet

Une dame, nous allons l'appeler Mme Rite, a insisté à me suivre autour de sa cour comme je l'ai tondue. Elle se plaignait de la hauteur de la tondeuse, la façon dont je empoché l'herbe, et la façon dont je m'ont attaché les chaussures de sport. En plus de tondre la pelouse, cette princesse a également appel à moi pour tirer les mauvaises herbes, ratisser les feuilles, couper les arbustes, nettoyer les gouttières, et des tonnes de plus-en fonction de la météo et quand son coven n'était réunion.
Ce n'est pas que je ne veux pas faire toutes ces tâches, c'était les observations constantes et l'ajout d'activités que j'ai terminé ce qui était convenu. Pour Mme Rite, le nettoyage des gouttières aurait pu facilement étendu en remplacement des bardeaux. Planter un arbre de petite taille pourraient avoir tendu dans l'installation d'une piscine creusée. Pour elle, un accord fut pas une affaire si elle a obtenu ses 20 dollars. Je redoutais chaque projet que j'ai fait pour elle parce que je savais qu'elle avait changer l'activité dès que "nous" a commencé. Ah les joies.
La seule chose que j'ai appris de cette clientèle exigeante, c'est que vous devez avoir clairement défini leurs conditions d'agrément avant de commencer. Si seulement j'avais appris cette leçon quand j'avais 14 ans, j'aurais pu acheter quelques paquets de plusieurs des cartes de baseball. Lorsque Mme Rite m'a embauché pour arracher les mauvaises herbes, je pourrais avoir souligné que le travail signifiait que les mauvaises herbes qui étaient visibles autour de sa cour, non pas celles qui pourraient être dans le vide sanitaire ou qui pourraient surgir durant la nuit.
Si j'avais su alors ce que je sais aujourd'hui, j'aurais défini le champ d'application.
Définir la portée du projet
Dans la gestion de projet (et dans une certaine mesure aux travaux de la pelouse), il existe en fait deux champs d'application différents. Le premier est la définition du produit, ce qui est le résultat final du projet va créer. Le champ produit est ce que les clients se concentrer sur ce qu'ils sont pour vous envisager de créer. La définition du produit décrit la chose ou un service qui existe à la suite de votre projet.
La portée du projet, d'autre part, décrit tous les travaux pour créer la définition du produit. Il comprend tous les travaux, et seulement les travaux nécessaires, pour mener le projet à livrer. Dans ma pelouse expérience de travail, la définition du produit aurait pu être résumée comme une pelouse bien entretenue approprié pour une photo-op pour Home and Garden magazine. La portée du projet devrait inclure les détails sur la façon d'y arriver: Tondre la pelouse, tirer les mauvaises herbes, de l'assiette et le bord de la propriété, et la ligne des arbustes.
La portée du projet et le soutien étendue des produits entre eux. Dans le monde des TI, si vous créez une demande d'un intervenant, ils ont des attentes de ce que l'application va faire. Quand ils examineront les besoins avec vous, ils décrivent le résultat final de l'application. Les intervenants pensent en termes de vision, du produit existant. Ils peuvent voir dans le futur et l'expérience de la demande avant qu'il ne soit créé. Les intervenants ont généralement une façon de voir le problème résolu et l'organisation de leur solution, et peuvent ressentir un sentiment de soulagement et de l'urgence pour obtenir le produit livrable en production.
Malheureusement pour les gestionnaires de projet, certains intervenants n'ont pas ce don. Leur approche des exigences de collecte est plus comme Mme Rite. Ils ne savent pas ce qu'ils veulent jusqu'à ce que vous faites le travail. Ces intervenants ont un leitmotiv commun: «Je ne sais pas ce que je veux, mais ce n'est pas ça." These are fantastic et joyeux fois pour un chef de projet (qui est le sarcasme, bien sûr).
L'objectif des exigences en matière de collecte, pour ceux d'entre vous qui n'avez pas vécu ces Wishy intervenants washy, est de définir exactement ce que le projet va créer. Pour la plupart des gens, il est parfaitement logique, si vous ne savez pas ce que le projet est censé créer, le projet échouera.
Parfois, ce n'est pas la faute de la partie prenante, parfois c'est vraiment la faute du chef de projet. Si le gestionnaire de projet ne rend pas la même vision que les parties intéressées a pour le résultat final, il est lui-même la mise en place pour l'échec. Je sais que certains gestionnaires de projet (et je parie que vous faites, aussi) qui sont venus à grimper les échelons de l'informatique. Leur origine se trouve dans la technologie, ils sont des génies techniques, et ils peuvent configurer des serveurs Novell pour faire des toasts. Le problème est que certains de ces gens ne prennent pas le temps d'écouter ce que le client demande réellement. Ils ne prennent pas le temps de saisir l'étendue de produits. Ils ne peuvent pas voir le résultat final que le client voit.
Les gestionnaires de projet technique graviter vers une solution qui résout le problème, ils pensent qu'ils connaissent plutôt que le problème le client dispose. Nous n'avons pas vraiment besoin de directeurs de projets techniques. Permettez-moi d'écrire ce nouveau afin que vous ne pensez pas que c'est une faute de frappe: Nous n'avons pas besoin des gestionnaires de projet technique.
Nous avons besoin de chefs de projet qui peut capturer ce que le client veut. Nous avons besoin de chefs de projet qui écouter les clients décrivent leur vision de ce que le projet va créer. Nous avons besoin de gestionnaires de projet qui peut vous écouter, interroger, la recherche, et revenir sur le problème que les besoins des intervenants résolu. Ou qui peut travailler avec le client pour s'assurer que le projet permettra de saisir une opportunité. Ou qui peuvent compter sur leur équipe de projet pour créer une solution qui fait les deux. Chefs de projets techniques sont superbes, mais je vais prendre un gestionnaire de projet qui écoute et comprend l'objectif du projet tous les jours.
Si vous n'obtenez rien d'autre de cet article, obtenez ceci: Vous ne-doit-pas commencer un projet avant de connaître les conditions d'acceptation. On voit ça tout le temps: Vous ne voulez pas construire une maison sans savoir ce que la maison va ressembler à l'achèvement. Vous ne voulez pas créer un centre d'appel sans décrire l'objectif et les caractéristiques du centre d'appels. Vous ne créerait pas une voiture sans specs sur ce que la voiture doit avoir. Je comprends que la technologie est fluide, et que, comme responsables de projets informatiques, nous devons être capables de s'adapter et d'évoluer, mais nous devons avoir des spécifications claires de ce que l'objectif devrait être avant de procéder au projet. Sans une vision claire des éléments livrables du projet, le projet est condamné.
Documentation Means Everything
Après le chef de projet et le client sont d'accord sur ce que le projet permettra de créer, le gestionnaire de projet devrait créer un énoncé de la portée, qui est un document qui capture tout ce qui est considéré dans sa portée et définit les choses utiles qui sont hors de portée. Par exemple, un projet visant à pousser une application à 1.500 postes de travail pourrait définir l'application, de définir la vue d'ensemble des travaux du projet et de souligner que le déploiement ne comprend pas de visiter toutes les machines afin de confirmer l'existence de la poussée. L'énoncé de la portée précise du projet et impose au gestionnaire du projet, le promoteur du projet, et parfois les acteurs clés de signer sur le document.
L'énoncé de la portée sert de guide pour toutes les décisions du futur projet. La figure suivante présente le scénario du projet et l'influence pertinente du chef de projet et les intervenants. Au début du projet, les parties prenantes devraient avoir un tas d'influence, leur contribution est indispensable. Alors que le projet progresse vers la fin, un avis que l'influence des acteurs diminue avec l'augmentation influencer le chef de projet. L'intersection des deux voies représente la création de l'énoncé de la portée.


En d'autres termes, une fois l'énoncé de la portée a été convenu, le gestionnaire du projet possède le projet et travaille à protéger et à respecter les engagements établis dans la déclaration sur la portée.
Création de la Work Breakdown Structure
Une fois la déclaration sur la portée a été écrit, il est temps de se décomposer. Eh bien, pas vous, le champ d'application. A Work Breakdown Structure (WBS) est une décomposition orientée livrables du projet. Ce n'est pas les activités nécessaires pour créer les éléments livrables du projet, c'est de l'étoffe dont les activités créer.
Gasp!
That's right. Un WBS n'est pas l'œuvre, mais les résultats attendus. Certaines personnes dans le monde IT (je ne les citerai pas de nom, mais leurs initiales sont Microsoft) ont faussé cela un peu. Si vous avez déjà utilisé Microsoft Project, un très bon outil, vous mai ont été amenés à croire que la liste des activités, la vue par défaut dans Microsoft Project, est la WBS. Il n'en est rien.
Un WBS est pas les activités réelles, mais les produits à livrer que le client attend de la réalisation du projet. Supposons que nous allions à installer un réseau à partir de zéro à cinq endroits différents à travers le pays: nord de la Californie, Tacoma, Philadelphie, Atlanta et la nous aurions quelques grandes catégories de choses pour notre projet:
1. WAN
2. LAN
3. Systèmes d'exploitation
4. Education
Ces grandes catégories de choses peuvent être ventilés de nouveau pour plus de choses que nous livrerons dans le projet:
LAN WAN Systèmes d'exploitation Education
Contrats ISP Workstations Commutateurs professionnel de l'éducation
Routers Switches vérins utilisateur mur de la fin de l'éducation
Serveurs du réseau local de traiter les régimes de propriété intellectuelle des schémas d'adressage
WAN diagramme Panneaux de brassage
Voir la façon de les décomposer en plus de choses? Nous sommes en décomposition la portée du projet dans les choses que le client recevra à la suite du projet. Stuff, pas des activités. Le résultat final de l'OTP est une image claire de ce que le client peut et ne peut pas obtenir dans le cadre du projet.
Jusqu'où faut-il abattre les éléments livrables du projet? Vous pouvez (non pas que vous voulez) se décomposent vos livrables WAN jusqu'à la noix et des boulons dans le rack that'll la maison du matériel.
Vous voulez suivre la règle "8 / 80" lorsque vous briser votre portée du projet. La Règle 8 / 80, qui n'est vraiment pas une règle mais une ligne directrice, demande que la plus petite livrable dans l'OTP, appelé le lot de travaux, assimilent à un maximum de 80 heures de travail et pas moins de 8 heures de travail pour créer que les produits à livrer. Vous ne voulez pas devenir si granulés ou si vagues avec votre WBS qu'il est incontrôlable et inutile.
Mais à quoi bon encore la création d'un WBS? Il ya un tas de raisons pour lesquelles un WBS exacts et complets doit exister, mais il ya cinq raisons importantes pour lesquelles chaque projet a besoin d'un WBS (discuté dans les sections suivantes).
Cost Estimating
Parce qu'un WBS vous exige et votre équipe de projet pour tenir compte de tout ce que vous pourrez créer, vous pouvez créer des estimations de coûts très précise de ce que le projet coûtera à remplir. Cette estimation, qui arrive un peu après votre commande approximative de l'estimation de l'ampleur (ROM), est appelée l'estimation définitive, et c'est la plus exacte. Vous savez mai estimations ROM dénommé estimations couloir ou des estimations approximatives.
Coût budgétaire
Budgétisation des coûts est l'argent réel engagé sur un livrable du projet. Une fois l'estimation des coûts a été créé, nous devons suivre en temps réel et les dépenses de matériaux qui vont dans la création de l'OTP à livrer. La différence entre ce qui était prévu et ce qui est réel est la variance des dépenses. Budgétisation des coûts permet au gestionnaire de projet et la direction de suivre la ligne de base des coûts du projet.
Planification des ressources
Comment savez-vous combien d'aide dont vous aurez besoin pour terminer le projet? La plupart des gestionnaires du projet reposent sur le jugement d'experts, l'expérience et intuition, mais la structure de répartition fait apparaître les éléments livrables et le talent requis pour créer des produits livrables. Par exemple, dans notre WAN / LAN projet, une de nos tâches pourraient être des routeurs Cisco. Cet objectif pourrait nous obliger à embaucher ou de contracter un CCIE pour configurer notre réseau.
Risk Management Planning
Le risque est un événement incertain qui peut avoir des effets positifs ou négatifs sur notre projet. Le WBS permet de considérer les circonstances et les conditions de chaque livrable pour des risques au sein de notre projet. Une fois que nous avons identifié les risques, nous pouvons alors leur pelle par une analyse qualitative et quantitative de capturer ce qui risque de nous avons besoin pour atténuer et lesquelles nous pouvons vivre avec.
Activité Définition
Soupir de soulagement, non? Une fois que nous avons créé la structure de répartition, nous pouvons alors définir les activités nécessaires pour créer réellement les livrables que le client attend. Nous avons besoin d'identifier tous les résultats que le projet permettra de créer ainsi que nous pouvons identifier toutes les activités visant à créer le projet.
Décemment et en ordre
Parfois nouveaux gestionnaires de projet sont frustrés à tous ces processus et des procédures supplémentaires, et qui veulent simplement se rendre au travail. Rookie erreur. Projets, et bien ... les projets retenus, de suivre un système éprouvé pour se rendre à l'exécution du plan de projet. S'il y avait un Robert's Rules of Order for Project Management, la priorité de toute cette activité serait quelque chose comme ceci:
1. Obtenez une charte du projet.
2. Créer l'énoncé de la portée du projet.
3. Créer le WBS avec l'équipe projet.
4. Créer la liste des activités de la WBS.
5. Activités de la séquence dans l'ordre dans lequel elles doivent-ils ou devraient-passer.
6. Estimez le temps des activités sur la base duquel les ressources que vous avez à compléter les activités.
7. Affecter les ressources nécessaires aux activités.
8. Get it done.
Bien sûr, c'est un résumé rapide de la façon dont l'équipe du projet se met au travail dans un monde parfait. Je me rends compte qu'il ne va pas toujours de cette façon: dans le monde réel, les projets échouent souvent.
Une fois la portée a été définie, la SRT a été créé, et les clients signent les deux documents, le gestionnaire de projet veut verrouiller les ajouts ou modifications. C'est le contrôle le changement de portée. Combien de projets avez-vous travaillé sur l'endroit où le client tape à votre porte tous les jours avec quelques centaines de changements pour le livrable du projet? Bon, peut-être qu'ils ne tapait pas sur votre porte tous les jours, mais je parie qu'ils pop avec quelques «moments oh-yeah." Ou ils sont tellement impressionnés par le bon travail de votre équipe fait qu'ils se rendent compte que vous pourriez facilement travailler dans un peu plus de détails pour eux. Right?
Oh les horreurs.
Une fois par la portée du projet et WBS a été convenu, c'est à la gestionnaire de projet pour s'assurer que l'équipe du projet et le client que les changements ne seront pas facilement admis dans le projet. La façon dont cela va fonctionner que si le gestionnaire de projet communique au client, le suivi et solidement documentés Change Control System (CCS). Un CCS sert comme d'un bouclier de changements inutiles et bouffi. Il exige du demandeur de documenter la demande de modification, pourquoi le changement est nécessaire, et les ramifications de la livrable du projet si le changement est refusé.
Provenant du demandeur, le changement est promu au gestionnaire, promoteur du projet, ou directement au chef de projet. Finalement, le changement mai être promu à un conseil de contrôle des changements (CCB), où il ya des gens joyeux va débattre de la valeur et la dignité de la modification proposée, et peuvent choisir de refuser ou approuver la modification proposée.
Tout changement qui est sérieusement envisagée doit avoir beaucoup de recherches pour déterminer l'influence de la demande de modification sur le reste du projet. Au minimum, le changement doit être évalué pour les attributs suivants:
· Ramifications de décliner la demande de modification.
· Risque d'accepter le changement.
· Coût et de temps pour comprendre le changement demandé.
· Effet du changement sur la qualité du projet.
· Effet du changement sur les décisions d'acquisition, de contrats et des finances.
· Effet de la variation ou une série de changements sur la capacité de l'équipe de projet à la réalisation du projet dans les délais.
· Effet du changement sur le moral de l'équipe de projet.
· Effet du changement sur les chances du chef de projet d'une promotion ou bonus. Kidding.
Qu'on le veuille ou non, certains changements sont grands pour le livrable du projet, et il est logique de les inclure dans la portée du projet. D'autres changements de nouveau le veuille ou non, ne sera pas bon pour le projet. Tous les changements, bons ou mauvais, doivent être documentés et étudiés. Cela prend du temps. Une vague de demandes de changement, même s'ils sont tous baissé, ce sera presque tirer le gestionnaire de projet et / ou l'équipe du projet loin de leur objectif d'obtenir le projet travail accompli. Un documentées et CCS de travail est obligatoire pour toute organisation.
Alors comment savez-vous quand le projet est terminé? Certains vont dire quand vous êtes à court d'argent ou de temps. Dans une certaine mesure, c'est vrai, si la planification a été fait avec précision, le projet devrait se terminer à temps et sans fonds restants. Mais ceci est censé être un débat réaliste sur la gestion de projet.
Les projets sont finis lorsque la portée du projet a été achevée. Un projet est terminé lorsque la portée du projet correspond à l'état présent. Un projet est terminé lorsque le chef de projet et le client du projet peut prendre l'OTP et cochez chaque élément comme liste d'achats la semaine dernière. Il est ainsi prouvé sa portée.
Portée de vérification est tout simplement le gestionnaire de projet et le client du projet inspecter les éléments livrables du projet pour s'assurer que toutes les promesses faites dans le plan du projet existent dans le livrable du projet. Il ya mai de retravailler, de mesures correctives ou des demandes de dernière minute pour changer la réalisation du projet, si tout se passe comme prévu, le gestionnaire de projet et le client sont d'accord que les produits livrables équivaudraient à la portée du projet.
Cela prend du temps.
Que vous gérer la création de logiciels ou de construire une nouvelle maison de quatre chambres à coucher, il ya généralement une fenêtre d'opportunité pour le client et l'équipe du projet à continuer de travailler ensemble pour assurer que les livrables sont bonnes et fonctionnent comme prévu. Cela peut se faire par une entente de service ou une garantie. L'essentiel, c'est que la plupart des grands projets ont une certaine quantité de temps alloué pour le client d'utiliser le livrable et de signaler tout problème au responsable de projet pour des corrections ou de soutien.
Cette entreprise a besoin d'être définis à l'avance, elle ne peut pas être laissé à des hypothèses. Ce n'est pas drôle quand le client suppose que vous et votre équipe de projet serait l'appui du service à fournir pour l'éternité si l'on suppose que vous serez le soutien du service à fournir pour les trois prochains mois. Pas drôle du tout. De façon précise un plan opérationnel de transfert, la garantie, ou convenu niveau de service doivent être définis au début du projet. Et puis de le coller.
Si seulement j'avais su ce métier dos quand je transpirais des travaux de la pelouse pour Mme Rite. Gestion de la portée, grands ou petits, se résume à un accord sur ce que le projet peut et ne pas livrer. Alors les deux parties doivent vivre par l'accord. Après tout, un engagement, c'est un deal.