Quelquefois même, nous ne partageons pas toutes les informations échangées par nos supérieurs hiérarchiques, ce qui rend notre vision du projet purement “mécanique”.
Or, les enjeux d’un projet web dépassent largement ceux de l’équipe projet, comme en attestent ces “signes” avant-coureurs d’un avenir incertain…
Si vous ressentez un soudain sentiment d’incertitude, posez-vous ces 10 questions et soumettez-les discrètement à vos supérieurs, leurs réponses pourront vous étonner !
1. Le projet repose sur le rêve de la direction, mais personne n’a vraiment cherché à mesurer sa valeur pour l’entreprise.
Il apparaît quelquefois qu’un projet soit initié au détour d’un Comité de Direction, à l’initiative de personnes bien pensantes, mais déconnectées de la réalité du business on line. Le brief de départ peut alors paraître décalé par rapport à l’usage que les clients internes ou externes en auront. Comment décider si telle ou telle fonctionnalité fait partie du périmètre ? Quels sont les résultats de l’étude d’opportunité ? Quels moyens doit-on affecter à la gestion du site ? Quels sont les enjeux pour l’entreprise ? Ces questions ne peuvent être éludées et conditionnent la réussite du projet.
2. Le commanditaire est trop occupé pour écouter et à trop faible pour assumer.
Ce point est crucial pour la vie d’un projet. L’un des points essentiels d’un projet web est qu’il accueille les demandes de nombreux interlocuteurs dans l’entreprise et qu’il appelle de nombreux arbitrages : c’est bien la maîtrise d’ouvrage qui doit les assumer, pour peu qu’elle y accorde du temps et de l’attention. Sans “pilote” interne, un projet n’est pas mobilisateur et ce sont bien souvent les personnalités qui prennent le pas sur les enjeux d’entreprise.
3. La direction souhaite entamer le projet, sans se soucier du planning.
Ah, le planning … Faut-il piloter par le planning ? Par le périmètre ? Par les deux ? Ces questions reviennent constamment lors d’un projet, si elles n’ont pas été statuées dès l’origine. En effet, il est rare d’identifier clairement tous les aspects fonctionnels d’un projet et par la même, d’y affecter les charges et les ressources suffisantes. Là encore, si aucun planning n’est établi, aucune visibilité n’est donnée aux commanditaire et il y a de fortes chances pour que les délais souhaités soient largement sous-évalués par rapport à ce que vos équipes sont en mesure de produire … sauf à sous-traiter largement et donc à exploser le budget. Une autre discussion s’engage alors … Le planning est un point essentiel d’un projet web, qui conditionne la bonne réalisation des fonctionnalités du site, sa bonne compréhension par les équipes internes et son pilotage dans le temps.
4. Les délais sont estimés par la direction.
La tentation est grande de mesurer au doigt mouillé les phases d’un projet. Sans identifier les charges des participants dans l’entreprise, qui n’y consacrent souvent qu’une partie de leur journée … posent leurs vacances en pleine recette … rallongent d’autant le chemin critique sur les tâches qui leur sont affectées … et produisent des nœuds d’étranglement difficilement contournables, sauf à les faire assumer par d’autres personnes en interne, à former, puis à désigner comme responsables de telle ou telle fonctionnalité. Ou bien alors à sous-traiter (cf point précédent). Le planning doit donc être établi par les personnes de l’art, qui seules ont une perception juste des charges nécessaires au bon déroulement du projet.
5. Le chef de projet ne détient pas toutes les informations contractuelles.
Bien souvent, les conditions commerciales répondent à des enjeux … commerciaux. Quoi de plus normal me direz-vous. Mais s’il s’agit de réaliser un site conforme à un besoin client, le prestataire s’en tiendra à ce que le client a acheté, et non à ce qu’il a interprété de sa réponse. Un matrice des exigences vous permettra d’éviter ce souci, qui peut s’avérer majeur lors des phases de conception.
6. La Direction demande au chef de projet de résoudre de conflits auprès de la maîtrise d’ouvrage pendant le projet.
Le trio constitué par la Direction Générale - le sponsor -, la maîtrise d’ouvrage et la maîtrise d’œuvre doit être régi dès l’entame du projet. Chacun tient un rôle dans le projet et nul ne peut s’en soustraire, n’y en déborder. Si les relations entre le sponsor et la maîtrise d’ouvrage se détériorent, ce n’est pas ua chef de projet d’y apporter des solutions, du moins pas en cours de projet. Ainsi, des demandes formulées par la maîtrise d’ouvrage ne sauraient être couvertes par le sponsor, si elles ne font pas partie du périmètre. Veillez à bien décrire chaque entité participante, pour ne pas vous retrouver dans une impasse et être “chargé” d’un conflit d’intérêts survenu en cours de projet !
7. La maîtrise d’ouvrage ne propose pas des profils adéquates.
Une des clés de la réussite d’un projet réside dans la capacité de la maîtrise d’ouvrage à assumer ses validations. Si l’application n’est pas correctement recettée (et je ne parle pas de la recette technique), elle ne remplira pas les besoins de la maîtrise d’ouvrage. Et en cela, seule les clients finaux sont capables de s’en assurer. C’est la raison pour laquelle l’assistance à maîtrise d’ouvrage n’assume que la supervision de la recette, car ce sont bien les utilisateurs finaux qui sont garants de sa conformité avec leurs besoins.
8. Les représentants du client acceptent de travailler officiellement, mais refusent de le retranscrire par écrit.
Les paroles s’envolent, les écrit restent. Seuls les écrits feront foi en cas de conflit et un refus de s’engager formellement - signature de PV de recette, validation fonctionnelle formelle, approbation des compte-rendus de séance, sont des actes qui engagent le client. Une des erreurs est de considérer que la non-révocation d’un document dans un délai entraîne de fait sa validation. Si cela peut s’appliquer pour des livraisons itératives,il est impératif de faire signer des PV de validation formels lors des livrables qui entraînent des facturations. If not …
9. Les attentes du client sont trop élevés et sont mal gérés par chef de projet.
Il est bien plus aisé d’accepter une demande que de la refuser. Tant sur le plan humain que sur celui de la compétence, refuser une demande client introduit -) à tort - un sentiment de défiance entre un client et son prestataire. Or, un périmètre fonctionnel ne peut être dépassé, sauf à en mesurer les impacts sur le projet (et bien souvent la surcharge financière engendrée). Et cela quelque soient les bonnes relations que vous entretenez avec vos clients et prestataires…
10. Le chef de projet redoute de perdre son emploi ou de contrarier son client.
Nous évoluons tous dans des structures où nous ne sommes que des rouages … Même si le pilotage d’un projet est un acte majeur dans un projet informatique, la responsabilité d’un chef de projet est de maîtriser les dérives d’un projet, quelqu’en soit le demandeur. Cela pour le bien de ses équipes - un planning rallongé nuit à la motivation des équipes - ou de son projet - les dérives fonctionnelles fragilisent l’urbanisation d’un projet -.
Soyez donc vigilant lorsque vous sentez qu’un de ces facteurs vire à l’orange et sachez en mesurer les impacts sur le court et le long terme !