Chef de projet : un métier complexe

Rigueur, ouverture, disponibilité, intégrité, bon sens, organisation, anticipation, écoute active, autodiscipline, capacités analytiques, diplomatie, leadership, transparence, proactivité, capacités relationnelles, professionnalisme… Voilà tout ce qu’on demande à un chef de projet aujourd’hui : de réunir l’ensemble de ces qualités… et la liste pourrait s’allonger. Un « mouton à cinq pattes », allez-vous dire. En effet, dans un environnement complexe, de surcroît, contraint par le time to market, il doit (faire) développer un produit au moindre coût dans des délais de plus en plus courts avec une qualité irréprochable.

Capitaine du navire, chef d’entreprise ou chef d’orchestre, clé de voûte de l’édifice que constitue son équipe, le métier de chef de projet est loin d’être simple et confortable ! D’autant que si tout va bien, il recueille rarement les félicitations du client ou de sa hiérarchie (« après tout, il n’a fait que son travail ! ») ; en revanche, si quelque chose tourne mal, il en sera responsable.

Manager les hommes et les femmes

Indépendance d’esprit, oui, mais la capacité du chef de projet à mobiliser l’ensemble des acteurs du projet facilitera l’atteinte des objectifs.

Une fois l’équipe constituée, le chef de projet doit rassembler, pour amener l’équipe à comprendre la vision du projet, à l’accepter et à la partager.

La méthodologie de gestion du projet mise au point sera communiquée, afin que chacun applique les processus et procédures définis. La tolérance et l’ouverture d’esprit du chef de projet faciliteront l’adaptation de cette méthodologie au fil de l’eau. C’est sa compétence
de leader et ses capacités à bien communiquer qui favorisent cette adhésion. On sous-estime souvent la dimension managériale de la fonction du chef de projet ; on décrit trop souvent ce dernier en réduisant son rôle à la construction de diagrammes de Gant et à la rédaction de plans projet dans lesquels il décrit sa stratégie. Avant tout, il est un chef d’orchestre, animé par le souci de réaliser une oeuvre collective, avec des profils et des rôles variés. Sa tâche consiste à rendre cohérent le jeu de l’ensemble des acteurs en leur donnant un rythme commun.

Le succès du manager passe par la confiance qu’il doit gagner et que lui témoignent les membres de l’équipe ainsi que par la sécurité et la solidarité ressenties au sein du groupe face à l’extérieur (hiérarchie, clients…).

Accepter l’incertitude

La première est d’accepter l’incertitude, pour mieux la maîtriser, et non la combattre. Il s’agit d’accepter une réalité et de comprendre que, dans le développement logiciel, tout n’est pas prévisible.

D’une part, parce que le secteur informatique est une industrie jeune, comparée à l’industrie automobile, par exemple, qui a plus d’un siècle d’expérience. D’autre part, parce qu’il est difficile de s’entendre avec le client, « une bonne fois pour toutes », sur ce qu’on
va livrer. Et aussi, parce que les techniques d’estimation et de planification ne sont pas des sciences exactes.

Chaque projet est une nouvelle expérience ; en acceptant l’inconnu d’un projet, plus ou moins important, selon qu’on est sur un projet d’exploration ou de maintenance, le chef de projet évitera de se retrouver en situation d’échec.

Si on accepte l’incertitude, on accepte aussi l’idée du changement : changement dans le périmètre des besoins, changement dans la planification, changement dans l’organisation de l’équipe… pour s’adapter aux imprévus.

Méthodes traditionnelles ou méthodes agiles ?

Depuis des décennies, les projets sont gérés avec une approche classique, le plus fréquemment « en cascade » ou son adaptation « en V », basée sur des activités séquentielles : on recueille les besoins, on définit le produit, on le développe puis on le teste avant de le livrer au client.

Ces méthodologies se caractérisent par un attachement farouche à tout planifier, « tout doit être prévisible », en tout début de projet. Voilà pourquoi on les qualifie d’approches « prédictives ». Un plan de management du projet décrit comment et quand le travail sera réalisé, les modalités de planification, d’exécution, de suivi et de clôture du projet. Cette volonté persistante de vouloir piloter le projet par les plans (plan-driven development) a conduit les acteurs d’un projet à redouter, voire à s’opposer systématiquement à tout changement : changement dans le contenu ou le périmètre du projet, dans le processus de développement, au sein de l’équipe, bref à toute modification des plans initiaux, auxquels on doit rester conforme.

« Quand on trouve une recette qui marche bien, on a du mal à la quitter même si l’on constate que son efficacité semble diminuer ; il existe une inertie due à la peur du changement, à la recherche de facilité ou à l’ivresse du succès (ce qui marchait hier doit marcher demain…). Eh bien non !!! »

Fort du constat que les plans initiaux sont finalement toujours modifiés et que les besoins évoluent en permanence pour répondre aux changements du marché, ces approches prédictives se sont révélées trop « rigides » parfois, exposant les organisations à trop peu
de réactivité dans le contexte de nouveaux projets stratégiques.

Sont alors apparues, des méthodes moins prédictives, plus souples face aux besoins d’adaptation, facilitant ainsi l’agilité des organisations face aux contraintes du marché.

Ce sont les méthodes dites « agiles».

Méthode traditionelle (Cycle en Cascade) : Une documentation pléthorique

Afin de se prémunir contre ces risques, l’approche « en cascade » s’attache fortement à la production d’une documentation importante.

La documentation permet de repousser le moment où il va falloir aborder la phase de codage, phase irréversible.

Elle rassure et, s’il en était nécessaire, elle apporte la preuve que la réalisation progresse; elle matérialise l’avancement et engage les parties prenantes. En effet, il est plus aisé de s’opposer au changement en brandissant un document contractuel validé précédemment !

Malheureusement, cette documentation, souvent trop pléthorique, ne reflète pas la réalité des développements : on a beau valider un document d’architecture, celle-ci reste théorique et conceptuelle tant qu’elle n’est pas implémentée et testée dans des conditions réelles; on a beau présenter des maquettes papier au client, celui-ci est plus sensible à ce qu’il voit concrètement sur un écran (IKIWISI, I’ll Know It When I See It !).

Au final, on s’interroge sur l’utilité de cette documentation, qui n’est, en outre, pas toujours mise à jour tout au long du projet et devient donc vite inexploitable.

Dans ce contexte de méthodes trop rigides, comment augmenter le niveau de satisfaction des clients tout en facilitant la gestion des projets et en améliorant la qualité des développements ? C’est précisément avec les méthodes dites « agiles » que l’on va pouvoir adopter une approche plus souple, plus « adaptative » aux aléas du projet.

À propos de Hicham AIT BASLAM

Une expérience de 16 ans, passée dans le conseil et le management de grands projets complexes à dimension internationale impliquant des équipes pluridisciplinaires et hétérogènes culturellement, à traiter de problématique d’intégration (FrontOffice, BackOffice) et d’architecture SI, d’alignement du SI sur la stratégie de l’entreprise, d’amélioration continue de la qualité, des process de delivery et la performance des équipes. Elle est constituée sur le terrain par la direction de nombreux centres de delivery et programmes de la phase amont jusqu’à la réalisation et livraison, marquée aussi par la Transformation et Refonte de plusieurs SI Stratégique, par le redressement de projets informatiques en difficultés, Business développement de plusieurs SSII, développement de nouvelles offres sur le marché. Toutes ces expériences m’ont permis d’avoir une vision générale des systèmes d’information éclairés sous différents angles et sur les solutions globales à haute valeur ajoutée. Mon expérience, en tant que directeur de projet, manager « évangéliste » de l’agilité, et compte tenu de ma croyance profonde dans les valeurs de l’agilité pour les petites, moyennes ou grandes organisations, m’a conduit à travers la France et l’Afrique. J’ai eu suffisamment de chance pour être impliqué dans de vraies mutations organisationnelles et transformation SI basées sur les disciplines et les pratiques du manifeste Agile et l’approche DevOps. Aujourd’hui, je me positionne dans le management de business unit, centre de delivery, la direction des projets à fort dimension (Internationale, Managériale, Business, Technologique), je me consacre entièrement à accompagner de grands comptes à réussir la transformation de leur SI, la transition vers l’agilité et à la traduction de la vision stratégique en résultat.

Publié le 14/01/2013, dans Méthodes Agiles. Bookmarquez ce permalien. Poster un commentaire.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :