Get best of the week

Comment comprendre qu'un projet est un projet et l'exécuter correctement

Deux jours avant la démo. L'équipe a vu des fonctionnalités spécifiques - l'intégration de notre produit avec Google Maps. L'intégration est scannée "à genoux" - l'essentiel est d'avoir le temps de montrer au client potentiel les capacités du système.

La démo passe et le client s'arrête pour réfléchir.

Six mois plus tard, les vendeurs vendent une autre solution avec l'intégration de Google Maps à un autre client. Eh bien, ils ont vu qu'il y a six mois, tout fonctionnait sur la démo.

Quel est le problème ici?

J'ai travaillé dans différentes entreprises. Quelque part, il était clair que nous allions faire ce projet. Pourquoi était-ce clair? Le client est venu et m'a dit que je devais créer un tel système et le décrire. Le gestionnaire planifie combien le projet prendra en temps et en argent, négocie avec le client et travaille à l'avance. Il s'agit de la charte, du plan de projet, des risques, du contrôle qualité et des autres artefacts du projet. Clair et compréhensible.

Dans d'autres organisations, le projet a été lancé d'en haut - nous faisons ceci et cela, prenons les gens et partez. Moins d'étendues, mais aussi clairement et clairement.

Troisièmement, le plus difficile, avec des projets ce n'est pas facile. À mon avis, il y a un certain nombre de problèmes sur lesquels il m'est difficile de juger à mon niveau. Tout s'est passé comme décrit au début - le projet est probablement mort que vivant.

Quels problèmes surviennent?

  • , — . , .
  • .
  • , .

L'équipe de projet a commencé à élaborer le plan de mise en œuvre et des nuances «soudaines» sont apparues.

Un classique du genre, cependant - nous et le client avons compris différemment «intégration», par exemple, ou le terme «audit». Pour eux, c'était un mot terrible associé aux mauvais vérificateurs, et pour nous, un terme qui signifie fonctionnalité.

En conséquence, le processus de mise en œuvre se traduit par un projet de révision. Officiellement, le projet de charte n'a pas changé; tous les objectifs de haut niveau sont restés les mêmes.

Comment rouler? La tâche principale est de savoir exactement ce qui doit être fait, de déterminer les priorités, les délais, les ressources, les risques, d'informer toutes les parties intéressées, de préparer plusieurs scénarios de développement. En conséquence - pour convenir avec le client du montant requis qui s'intégrera dans le budget abordable.

Les principales nuances - le projet a déjà été vendu, il a déjà un budget et la quantité de travail. Restrictions assez sévères. Mais cela ne signifie pas que vous devez tout avaler et le prendre pour la vérité en premier lieu. Dans 99% des cas, vous pouvez négocier, que ce soit un client ou un sponsor.

Nous commençons le projet


Il se trouve que je suis davantage partisan de plans clairs. Waterfall et l'approche PMI sont similaires dans leur esprit, bien que certains aspects d'Agile ne soient pas étrangers.

Ainsi, le projet commence et la preuve que le projet est lancé est la charte du projet. Pour ceux qui sont peu familiers ou peu familiers, je vais expliquer de quel genre de bête il s'agit.

Selon l'idéologie de PMI, il s'agit d'un document qui décrit les objectifs de haut niveau, les délais, le budget, les risques, et donne également une autorité formelle au chef de projet et, surtout, détermine le nom du projet. Ci-dessous, je vais expliquer pourquoi.

Souvent, la charte est préparée par le chef de projet, en accord avec le sponsor, le client et d'autres parties prenantes clés.

Dans l'une des entreprises où je travaillais, il n'y avait pas de définition claire de ce qu'était un projet. Il y avait une certaine activité, un certain flux, qui s'appelait un projet, mais en fait ce n'était pas le cas. C'était une supposition. D'accord, appelons cela un projet et décidons au moins d'un nom pour que tout le monde comprenne de quoi nous parlons. Il y a eu confusion avec les noms, lorsque le sponsor a dit - "Quelle est la progression du projet d'intégration des solutions?", Puis le chef de département et le responsable ont réfléchi à différentes choses. Le chef de département a appelé ce projet «intégration client», et le chef de projet «optimisation de la base de données». Chacun pensait à son niveau.

Agile n'a pas de budget et de délais, même de haut niveau, car tout est flexible et peut changer à tout moment. Oui, Agile peut estimer le temps d'exécution, mais seulement après plusieurs itérations lorsque les performances de l'équipe sont évaluées. Mais il y a des objectifs. Nous savons ce que nous voulons faire.

Je vais vous donner un exemple. Il y a deux équipes de développement. Les deux ont le même projet - développer une solution mobile pour le contrôle de la qualité des aliments.

L'équipe A travaille sur Waterfall. L'équipe B travaille sur Agile. Différentes approches de la planification et du développement. Mais l'objectif est un. Alors pourquoi ne pas le réparer au début? Quelle est la probabilité que l'équipe B au milieu du sprint comprenne que le client n'a pas besoin d'une application pour le contrôle de la qualité, mais a besoin d'une application pour l'enregistrement des matchs de football? Très petits, avec une plus grande probabilité, ils atteindront néanmoins leur objectif initial.

NB: je fais une hypothèse et je parle de développement personnalisé, pas de startups.

Avec le nom, le timing, le budget, plus ou moins clair. Et les risques?

PMI se réfère à cela formellement. À mon avis, le processus de gestion des risques est une chose indépendante. Permettez-moi d'expliquer ce que je veux dire.

Le processus de gestion des risques comprend les étapes suivantes:

  1. Identification
  2. Une analyse
  3. Planification
  4. surveillance

Il s'agit essentiellement d'un processus itératif. Il est applicable aux opérations et aux approches Agiles.

Lors du démarrage d'un projet, il existe un risque global: il peut échouer.
Le livre d'Edward Yordon, The Kamikaze Path, a une pensée intéressante - cela vaut la peine de traiter tout projet comme un échec. Avec cette attitude, vous devez construire une stratégie de développement, c'est-à-dire réfléchir à un ensemble d'actions qui feront d'un projet réussi un échec.

Alors pourquoi ne pas vous éloigner de cette pensée et la concrétiser? Oui, il y a peu de données au départ. Mais c'est pourquoi ce sont des risques de haut niveau, afin de montrer aux parties intéressées ce qui pourrait mal tourner.
Total - le projet de charte est un document qui permet à toutes les parties clés de s'entendre sur une terminologie, des objectifs mondiaux et des risques de haut niveau. Tout le monde comprend où nous allons, ce que nous voulons réaliser et ce qui pourrait mal se passer.

Fixation des objectifs du projet


De nombreux chefs de projet novices sont passés par là - vous devez rédiger une charte et déterminer le ou les objectifs du projet. Et de tels monstres sont nés:

  • Élaboration et mise en œuvre d'un programme d'entreprise et d'un système de gestion de projet pour améliorer l'interaction entre les ministères;
  • Recyclage du système de comptabilité fiscale pour optimiser le processus comptable;
  • Mise en place d'un système de contrôle des coûts pour augmenter le profit des départements.
  • Ces projets ne peuvent pas être achevés. Si vous voyez ce libellé dans la charte, alors ce projet est déjà mort.

Pourquoi un «système d'entreprise» devrait-il améliorer la collaboration? Comment la cliente comprendra-t-elle ce qu'elle a fait?

«Recyclage du système comptable» - nous allons le retravailler, mais comment? Modifiez les éléments de menu dans l'interface. Cela simplifie-t-il le processus comptable?

«Mise en œuvre du système de contrôle» - comment comprenons-nous que le système est mis en œuvre? Supposons que tout le monde soit d'accord sur sa mise en œuvre, mais cela augmentera-t-il les bénéfices des départements? Et si nous ne mettons rien en œuvre, mais que le profit augmente, pour des raisons indépendantes de notre volonté? Peut-on supposer que le projet a atteint son objectif?

Si nous formulons les objectifs du projet, alors cela devrait être un ensemble d'objectifs: que faut-il faire spécifiquement et comment comprenons-nous que nous l'avons fait? Que devrions-nous voir, ressentir? Qu'est-ce qui devrait changer? Quels coûts devrait-on atteindre? Quand? S'il y a plusieurs objectifs, quelles sont leurs priorités. Il peut s'avérer que les objectifs dépendent les uns des autres, ou il peut s'avérer que certains objectifs s'excluent mutuellement.

Fixer des objectifs SMART


  • Spécifique - spécifique.
    Que voulons-nous faire? Quelque chose à améliorer? Et combien?
  • Mesurable - mesurable.
    Peut-on mesurer l'objectif en argent, en pourcentage, en temps gagné?
  • Atteignable - réalisable Avons-nous suffisamment de ressources, de connaissances, d'expérience, de temps pour atteindre l'objectif?
  • Pertinent - pertinent ou significatif.
    Ici, vous devez déterminer ce qui est nécessaire pour atteindre l'objectif?
  • Limité dans le temps - limité dans le temps.
    Combien de temps l'objectif devrait-il être atteint?

Exemple: Implémenter un système de gestion de projet basé sur Project Server pour 20 postes de travail du bureau de projet à l'aide d'un registre électronique des risques et de courriels avec fonction de notification automatique de report des délais.

Le système devrait permettre de réduire les délais de chaque projet de 15% dans les 2 mois suivant le lancement.

Le système devrait être mis en œuvre dans 6 mois, au plus tard le 15 décembre.

Déjà plus proche, mais toujours possible d'affiner.

Questions supplémentaires que vous pouvez poser:

  • Qu'est-ce qui devrait être fait?
  • Pourquoi avez-vous besoin de faire ça?
  • Quels avantages le projet devrait-il apporter?
  • Est-ce que tout le monde connaît ce plan?
  • Est-ce que tout le monde le comprend de la même manière?
  • Est-ce que tout le monde est d'accord avec lui?
  • Quand avez-vous besoin de terminer le travail?
  • Qui est l'utilisateur final?
  • Quelle qualité attendez-vous de recevoir?
  • Quelle fonctionnalité est attendue?
  • Quelles installations sont disponibles?
  • Qui contrôle le succès et selon quels critères?
  • Que ne devrait-il en aucun cas se produire?
  • Quel travail n'appartient pas au projet?

Les deux dernières questions sont les soi-disant «pas des objectifs».

Ils décrivent ce qui n'est pas pertinent pour le projet et ce qui ne devrait pas se produire, car cela interfère avec l'avancement du projet ou viole les restrictions internes. Les résultats qui ne sont pas pertinents pour le projet ne doivent pas être qualifiés de nuisibles, mais sachez que le client ne les paie pas.

Sommaire


Vous voyez, il y a une certaine quantité de travail avec certains plans et il y a même un calendrier et un budget pour cela? Avec un haut degré de probabilité, c'est un projet. Nous négocions avec les vendeurs afin que les managers et les ingénieurs soient impliqués dans le processus de vente. Au moins en tant que consultants - et ensuite ils travailleront avec.

Avant de commencer, nous déterminons le nom du projet et la terminologie. Nous rédigeons la charte et formulons des objectifs clairs et compréhensibles. SMART est notre tout.

More articles:


All Articles