Nombreuses sont les histoires de projets informatiques — petits ou grands — qui, dans le meilleur des cas, attendent la fin du cycle en V (voir note en bas de page) pour commencer à se poser des questions pour identifier des actions à mettre en œuvre (si le temps le permet) visant à s’améliorer lors du prochain projet. Lesdites questions s’appuient rarement sur des indicateurs autres que le respect des délais et les charges consommées versus prévues. Le reste des questionnements est souvent fondé sur du ressenti ou, si c’est mesuré, un nombre d’anomalie en recette client sans pour autant avoir dénombré celles détectées en recette interne (avant livraison au client). Pour le dire plus simplement, le questionnement se fait quasi exclusivement sur des données quantitatives, quand elles existent.
Cela parait assez caricatural. Pour autant, ami lecteur, si tu travailles dans le domaine de l’informatique, ne te retrouves-tu pas un peu (beaucoup) dans ces propos ? Je le concède, l’une des difficulté en Lean Management, c’est d’accepter de voir les problèmes. Le Pareto visuel va nous y aider.
Dans le cadre d’une démarche de 
Better, faster, together 