Parmi les outils du manager, que nous utilisons tous, figure l’analyse SWOT. J’ai lu dans un précédent numéro de Best Practices Systèmes d’Information (comme quoi j’ai de saines lectures… comme vous), que le SWOT sert à identifier le positionnement stratégique d’un produit ou d’un service.
Pour ceux qui l’ont oublié, les lettres de l’acronyme SWOT signifient : Strengths (forces), Weakenesses (faiblesses), Opportunities (pas besoin de traduire), et Threats (menaces).
Je suis sûr que vous en avez entendu parler, c’est la grande mode en ce moment, surtout pour les entreprises qui ne savent pas où elles vont, les fournisseurs qui sont dépassés par l’évolution de leurs marchés ou les managers qui ne savent plus où ils habitent. Ils se rassurent avec une telle analyse, même s’ils ne sont pas plus avancés après avoir réalisé une analyse SWOT. Tout juste savent-ils pourquoi ils sont nuls et quelles opportunités ils ne pourront jamais atteindre, avec leurs budgets faméliques et la cohorte de bras cassés dont ils sont entourés.
Appliquer le SWOT à la DSI est moins courant que pour la stratégie d’entreprise, mais cette approche commence à se répandre dans nos métiers. De toute façon, on a toujours des forces (celle de dire non, en particulier), des faiblesses (erreurs de recrutement, accepter des demandes irréalistes de la part des métiers…), des opportunités (quand on nous octroie le budget qui va avec…) et nous sommes confrontés à des menaces (DG, DAF, fournisseurs, utilisateurs, métiers, bref le monde entier…).
Mais tout cela est plutôt banal… C’est pourquoi j’ai « revisité », comme on dit chez les anglo-saxons, l’approche SWOT. Je n’ai pas changé le nom, mais je trouve que mon approche se révèle bien plus pertinente pour l’analyse des projets.
Ainsi, je propose de modifier la signification de ces quatre lettres, en fonction de la stratégie de gestion de projets. Ma méthode SWOT devient ainsi S (« Sauve qui peut… »), W (« Whaouu… trop top le projet mené par la DSI… »), O (« Ooops, encore raté… ») et T (« Tsss… ça ne marchera jamais… »).
Cela résume bien, à mon sens, les quatre issues vers lesquelles on peut s’orienter, lorsque l’on a la responsabilité d’un projet : soit il est tellement foireux qu’il faut immédiatement arrêter les frais, sous peine de créer des dégâts irréversibles dans le système d’information, selon le principe du « Sauve qui peut, le DSI, les développeurs, les femmes et les enfants d’abord ». Soit la DSI a fait de l’excellent travail et les utilisateurs n’auront alors que des louanges pour saluer l’expertise, le professionnalisme, la capacité d’innovation, la créativité (n’en jetez plus !), selon le principe de « l’effet Whaouu… ». Soit le projet est mal engagé et l’on devra reconnaître qu’il ne pourra aboutir (Ooops…). Soit, enfin, le projet suscite une telle perplexité, quant à sa pertinence et à la capacité de la DSI à le mener à bien, que tout le monde susurre : « Tsss… ça ne marchera jamais ! »
Il ne reste plus qu’à placer tous les projets en cours de développement dans les bonnes cases, et le tour est joué ! Un conseil : si vous avez beaucoup trop de projets dans les cases S, O et T, oubliez cette méthode et faites comme avant : rejetez systématiquement la responsabilité des échecs sur les métiers ! Et n’ayez pas peur : si vous ne savez pas pourquoi ils ont échoué, eux le savent certainement…
