L’importance de bien s’organiser

Mais bien sûr, quelle évidence! Et pourtant… Lisez ce qui suit et vous verrez que l’évidence se heurte souvent à un mur composé de différents matériaux : obligations, réalités, budgets, délais, objectifs…

Je suis sur le marché du travail depuis presque 20 ans et j’ai eu à gérer de nombreux projets, dans différents domaines d’activité, dans plusieurs pays et plusieurs langues, du côté agence et du côté client, dans le secteur privé et le secteur public. J’en ai donc vu de toutes les formes, de toutes les couleurs et pour tous les goûts!

Si je ne devais retenir qu’un seul enseignement de toutes ces expériences, ce serait l’impérieuse nécessité de réfléchir à l’organisation d’un projet avant de s’y lancer corps et âme.

Réfléchir à l’organisation d’un projet

Je m’explique. Très souvent, les clients nous demandent de commencer des projets avant même d’avoir établi une méthodologie de travail (parfois même sans avoir eu de réunion de lancement [kick off meeting]). Certes, tout dépend de l’ampleur du projet, mais je me réfère ici à des projets conséquents — et plus particulièrement aux refontes de sites Web — tant en ce qui concerne le nombre d’intervenants — internes et externes —, les volumes de contenu que les budgets.

L’excuse est très souvent la même : les échéanciers sont très serrés (l’autre excuse étant le budget). Pourtant, un projet lancé à la va-vite pour soi-disant respecter un échéancier va invariablement connaître des problèmes qui vont déboucher soit sur un lancement partiel, soit sur un report du lancement et sur des dépassements budgétaires.

Comme mentionné, mes expériences de tous bords, tous côtés me permettent de comprendre la réalité et les enjeux des uns et des autres. Et je sais qu’on ne peut consacrer des semaines à prendre du recul et du temps pour réfléchir à son projet. Mais prendre 2 ou 3 jours pour bien comprendre les implications et définir les étapes, les responsabilités de tout un chacun (aux niveaux interne et externe), le format des documents, les documents de référence à utiliser (par tous!), les informations à inclure dans les documents pour faciliter le travail des différents intervenants, la méthodologie… est une nécessité qui, en fin de compte, va limiter les surprises, en terme de retards et de dépassements budgétaires. Sans parler du niveau de stress et des insatisfactions des équipes.

Des exemples bien réels

Voici donc quelques exemples pour mieux illustrer mon propos, tous réels dans leur intégralité, mais remixés pour ne froisser personne.

— Un premier client se lance dans un projet de refonte de grande envergure avec des délais très serrés. Nous commençons à travailler avec des documents de référence. En cours de route, nous nous rendons compte que les différentes équipes du client n’utilisent pas les mêmes documents que nous. Lesquels conserver? Qui statue? Quels documents déjà livrés doivent être ajustés? Conclusion : une perte de temps qui occasionne un retard dans les étapes en aval, et donc dans le lancement du projet. Sans parler des coûts additionnels!

— Lors de la traduction de son site Web, un autre client approuve de nombreux documents en version française afin que nous commencions l’adaptation en anglais. Une fois cette phase du travail bien entamée, des modifications sont apportées à la version française. Et chacune des modifications doit être intégrée en anglais. Un travail de fourmi s’ensuit pour repérer les modifications, les faire valider en français puis les intégrer en anglais. Sans rien oublier en cours de route, évidemment. Les documents finaux correspondaient à la version 9! Et pourquoi? Parce que la chaîne d’approbation du client n’avait pas été définie. Heureusement, les dépassements budgétaires ne furent pas un enjeu, mais toutes les entreprises ne peuvent se permettre ce luxe.

— Un troisième client prend la décision de démarrer son projet de refonte sur plusieurs fronts en même temps. Les wire-frames sont développés sans tenir compte des textes à utiliser. Le découpage des wire-frames ne correspond pas aux caractéristiques du CMS retenu. Les TOC (Tables Of Content) qui en découlent ne correspondent donc ni à la réalité du CMS, ni à la réalité du contenu (textes et images). Mais, à la demande expresse du client, il faut malgré tout les remplir. Les conséquences de ne pas avoir suivi une méthodologie logique? Il a fallu ajuster les intitulés (pour faciliter le travail d’intégration en fin de compte) et les contenus de TOUTES les TOC! Un exercice qui a eu des conséquences néfastes quant à la date de lancement (et de toutes les activités de marketing, communication et relations publiques en découlant) et au budget. Sans parler de ceux qui ont perdu leur emploi à cause de cela…

De bons conseils

Bref, la précipitation n’est pas toujours bonne conseillère, mais dans le cas de projets majeurs comme ces 3 exemples, elle ne l’est jamais!

 

Comments are closed.