Discussion :

[Hinault Romaric]

25% des projets d'entreprise seraient en retard
D'après Sciforma, et dans la votre ?


Malgré les différentes techniques mises en œuvre pour la définition des coûts, l’élaboration du planning et du cahier des charges, les entreprises auraient du mal à respecter les timings de leurs des projets.

Une récente étude de Sciforma, éditeur de PSNext (un logiciel de gestion de projet) et de solutions Web de gestion de portefeuilles projets, montre que 25 % des projets d’entreprises ne respectent pas leurs délais.

Le questionnaire a été soumis aux entreprises françaises. Il révèle que ces entreprises gèrent simultanément en moyenne 139 projets. Les entreprises réalisant un CA annuel de moins de 10 millions gèrent en moyenne 40 projets. Dans celles ayant un CA compris entre 10 à 100 millions d’euros, ce chiffre passe à 71. De 100 à 1 milliard, à 138 projets. Au-dessus de 1 milliard de CA, les entreprises annoncent mener plus de 330 projets en moyenne.

Le secteur public est un des secteurs d'activité les plus dynamiques avec une moyenne de 540 projets en cours par collectivité territoriale.

Mais les entreprises éprouveraient d’énormes difficultés à respecter les plannings qu’elles ont établi. En 2010, les projets courts (<3 mois) ne sont tenus que dans les 2/3 des cas. Les délais des projets de 3 à 6 mois sont maîtrisés dans 72% des cas. Quant aux projets de 6 à 12 mois, ils sont de plus en plus nombreux à dépasser largement les limites initialement fixées (20,63% en 2010 contre 12,12% en 2009).

Autre enseignement, les projets longs sont parfois raccourcis. En effet, 5,26% des projets prévus pour durer plus de 12 mois ont, en réalité, été menés à bien en moins d’un an.

« Les entreprises françaises sont majoritairement passées « en mode projet » et gèrent en moyenne près de 140 projets en parallèle. Cependant, malgré l’implication des Directions Générales, les entreprises ont beaucoup de mal à respecter leurs plannings prévisionnels. Les projets dérapent », commente Stéphane Louit, Directeur Général Adjoint, Sciforma France. « Ce baromètre met en évidence des tensions importantes dans les entreprises entre les exigences opérationnelles quotidiennes et le besoin de se projeter dans le futur, des tensions qui se sont exacerbées en 2010 par rapport à 2009 » .

Les retards seraient dûs, pour un tiers des entreprises interrogées, au manque de compétences nécessaires à la réalisation de leurs projets, de méthodologie dans la gestion de projet et de qualification sur les principes de planification. L'absence de culture de projet ainsi que le manque de formations ont également évoqués.

Des raisons qui, selon Sciforma, traduisent à la fois la prise de conscience de l’importance de la gestion de projets dans la bonne conduite de l’entreprise et des difficultés à mettre en œuvre de tels projets.

Et dans la votre ?


Source : Etude Sciforma

[Heziva]

Perso, je suis assez fan des méthodes agiles pour réduire cette problématique. L'approche "on négocie le périmètre" plutôt que la date me séduit souvent.

Actuellement, je suis sur un de ces projets qui est bien en retard. Il est important dans ces cas là d'avoir du recul. Un truc qui m'aide bien, en ce moment, c'est de blogguer tous les soirs ce que j'ai fait dans ma journée. Ainsi, je peux me rendre compte de mon action par rapport au passage en agile de ma société...

[Heziva]

Ah. Et l'adresse (ça ne fait jamais de mal un peu de pub )

Passage aux methodes agiles

supprimez si ça n'a pas sa place ici.

[Marco46]

Ah ben 25% seulement c'est une performance, dans la boite que je vais bientôt quitter c'est 100%

[Teocali]

25 % ? Seulement ? Oo j'aurais parié bien plus.

Bon, après, je pense qu'il faut prendre en compte que tu ne vas pas donner de chiffre exact quand on te demande combien de projets sont en retard chez toi. Je pense que ça fait passer le chiffre a 35-40 %, deja (estimation au pifometre).
et après, faut aussi prendre en compte que tous ces projets ne sont pas au même stade : plus ton projet avance, plus il a de chance d'être en retard.

En tout, je prie pour un jour être sur un projet qui ne soit pas en retard. En 8 ans de carriere, ça ne m'est arrivé qu'une seule fois...

Teocali

[Traroth2]

Un planning prévisionnel n'est que ça, prévisionnel. Tenter une prévision au jour près, ce n'est pas de la bonne gestion de projet, c'est de la divination.

J'ajouterais que tant que la base de la planification, ça sera de faire un "retro-planning" à partir de la date à laquelle on aimerait que le projet soit bouclé, on s'expose à des dépassements. Personnellement, je n'ai jamais vu un projet planifié avec un "retro-planning" qui ait respecté les délais...

[Faiche]

Un planning prévisionnel n'est que ça, prévisionnel. Tenter une prévision au jour près, ce n'est pas de la bonne gestion de projet, c'est de la divination.

J'ajouterais que tant que la base de la planification, ça sera de faire un "retro-planning" à partir de la date à laquelle on aimerait que le projet soit bouclé, on s'expose à des dépassements. Personnellement, je n'ai jamais vu un projet planifié avec un "retro-planning" qui ait respecté les délais...

Ah, j'aurai pas mieux dit !
"Basé sur l'email que je vous ai envoyé, vous pensez finir dans combien de temps ?
- Je peux pas vous donner de chiffre avant de savoir TOUT ce qu'il y a à faire..
- Non, mais c'est juste pour moi, comme ça, pour me faire une idée"

Et là, c'est le drame : le chiffre est gravé dans le marbre, et peu importe le nombre de fois où le demandeur va changer d'avis, ajouter des fonctionnalités etc, cette date ne bougera jamais.
Donc oui, si on retire les menteurs, 25% des projets sont en retard.

[nonoxp]

25% ? Waw... on est des gens bons.
Il aurait été intéressant d'avoir le dépassement moyen en coûts pour pouvoir savoir si on est réellement performants. Je n'ai pas lu toute la source, mais une recherche rapide dans la page des mots "budget" et "coût" n'a rien donné.

Au final, ce qui intéresse la personne qui donne l'enveloppe, c'est qu'on soit égal à l'estimation $$$ ou à peine supérieur (pour justifier l'augmentation de budget l'année N+1). Des contraintes de délai gravées dans le marbre, c'est pour les projets politiques type "organisation de la coupe du monde" à budget virtuellement illimité.

Dans la vraie vie, bougez les délais, les ressources utilisées ou la qualité tout le monde s'adaptera (dans une limit acceptable bien sûr), par contre je suis moins sûr que ce raisonnement s'applique si on demande une rallonge en espèces en plein milieu du projet

C'est vrai que les méthodes agiles sont plutôt sympa quand la MOA et la MOE sont d'accord sur cette variable délai dès le départ. Si les entreprises sont en retard constant par contre, elles n'ont qu'à recruter... C'est bien beau d'avoir 38000 projets en parallèle, encore faut-il avoir les ressources pour absorber la charge de travail sinon adieu les délais.

[Wormus]

Moi aussi, ça m'étonne que ce ne soit pas plus !

Ah, j'aurai pas mieux dit !
"Basé sur l'email que je vous ai envoyé, vous pensez finir dans combien de temps ?
- Je peux pas vous donner de chiffre avant de savoir TOUT ce qu'il y a à faire..
- Non, mais c'est juste pour moi, comme ça, pour me faire une idée"

Et là, c'est le drame : le chiffre est gravé dans le marbre, et peu importe le nombre de fois où le demandeur va changer d'avis, ajouter des fonctionnalités etc, cette date ne bougera jamais.

C'est ça pour moi qui cause les plus gros problèmes dans le planning. L'ajout de fonctionnalités en cours de projet !

[Invité]

75% des entreprise ne répondent pas bien au questionnaire.

Et on entend quoi par retard ? retard par rapport a la première date annoncée ? Si c'est ça alors 100% des projets sont a la bourre

[Faiche]

C'est ça pour moi qui cause les plus gros problèmes dans le planning. L'ajout de fonctionnalités en cours de projet !

C'est de là que ça vient la gestion de projet agile : pouvoir résister au changement, en acceptant que le périmètre peut évoluer dans les deux sens (si on a le droit d'ajouter, on a le droit de retirer).

Un manager voudra toujours un périmètre pour un coût et un délai. Mais la réalité, c'est qu'il peut en choisir deux, pas trois.

[el_slapper]

On est tous d'accord, à quelques détails près. Le chiffrage, hormis des cas bien particuliers(modification correctement délimitée d'un existant que les intervenants connaissent par coeur), ça comprend toujours une partie de divination. Une bonne gestion de projet(agile ou pas, j'en ai vu d'excellentes en waterfall, même si pas souvent) aide beaucoup, mais un professionel sérieux SAIT qu'il va tomber dans des pièges. Juste, il ne sait pas combien, ni de quelle ampleur.

Et puis ensuite, il y a des traquenards. Là, j'avais estimé une modif à 14 jours. En 6 jours, je l'ai torchée(je me suis bien gamellé sur le chiffrage, mais je n'ai eu qu'un seul piège, alors que j'en attendais 7 ou 8). Résultat, tous les chefs vont pointer sur cette modif, dont ils ne savent même pas de quoi elle parle. Total : 14 jours. Ce qui fait que la prochaine modif de 14 jours que je fais en 15, je suis baisé. Les chefs, eux, vivent bien.

Je suis très d'accord sur la règle des 2 sur 3, que je ne connaissais pas, concernant le coût, le périmètre, et le délai. Il y a des exceptions, évidemment, mais la plupart du temps, ça sera vrai. Encore une fois, le agile, bien qu'interessant, n'est pas une solution miracle - si on met des incapables, ça donnera de la merde agile et adaptable, mais de la merde quand même. Le waterfall, quand il laisse lattitude à évoluer pour atteindre les objectifs, peut être très efficace. Là ou le agile est un poil supérieur à mon sens, c'est que son application stricte impose de l'adaptabilité, là ou une application stricte du waterfall ne mène qu'à un désastre garanti.

Exemple vécu :
"_Pour mettre au point la conception technique, il me faut vérifier une hypothèse technique. Je peux avoir une machine?
_Impossible, les développements n'ont pas commençé.
_Et on peut les commencer, juste pour un prototype?
_Impossible, la conception technique n'est pas terminée"

Dans ces conditions, évidemment, l'agile est la seule solution.

[Faiche]

En fait, pour qu'un projet waterfall fonctionne, il faut que les specs soient irréprochables : complètes, sans aucune ambiguité, et avec tous les cas couverts.

Je n'ai jamais vu le cas arriver.

Avec l'agile, ça ne fonctionne pas mieux, mais on s'en rend compte plus vite (quasi immédiatement en fait).

En fait, si on devait résumer : le waterfall ça marche sur le papier, si tout est parfait. L'agile prend en compte dans la méthode le fait que tout le monde se plante.

[nonoxp]

Encore une fois, le agile, bien qu'interessant, n'est pas une solution miracle - si on met des incapables, ça donnera de la merde agile et adaptable, mais de la merde quand même. Le waterfall, quand il laisse lattitude à évoluer pour atteindre les objectifs, peut être très efficace. Là ou le agile est un poil supérieur à mon sens, c'est que son application stricte impose de l'adaptabilité, là ou une application stricte du waterfall ne mène qu'à un désastre garanti.

Tout à fait d'accord. Le souci c'est que 80% des clients ne font pas de cahier des charges et dans ces 80% quand on les accompagne pour le réaliser, 50% déclarent forfait ou nous mettent ans les mains une personne complètement en dehors des problématiques. En face de ça en MOE on a des politiques de recrutement qui tirent le taux horaire réel en-dessous du smic et l'expérience moyenne vers le bas. D'où "l'évangélisation" de l'agile qui à mon sens n'est pas si mal, même si au final c'est 30 ou 50% de temps en plus qu'un waterfall.

Un waterfall sera forcément plus performant qu'une méthodo agile dans le monde idéal où les specs sont déjà rédigées, tout le monde compétent dans son job, dans un périmètre maîtrisé et souffrant de peu d'incertitudes. Mais dans ce cas là, la comparaison "développeur == pisseur de code" prend tout son sens.

[el_slapper]

En fait, vous parlez du waterfall pur, dur, et bestial. Quand on a des gens un peu intelligents et qui donc connaissent leurs limites, des modifs de specs en cours de projet, parfois même à la demande de la MOE, c'est possible. J'en ai obtenu. Mais ça restait un projet waterfall avec un document unique de référence(retouché, donc, plusieurs fois au cours du projet pour s'adapter aux surprises croisées) et une unique date de mise en prod. Et on a tenu, quasiment dans le budget prévu. Et ça n'a pas fait de moi un bête pisseur de code, puisque mon analyse a été prise en compte.

Mais je suis d'accord avec vous sur l'essentiel : quand une spec tamponnée et validée est intouchable, là, on va dans le décor. Et c'est assez fréquent en waterfall(plus gros dont j'ai été témoin, 60 personnes, 18 mois, poubelle, tous les chefs virés, à commencer par ceux qui ont tenté de sauver l'insauvable, mais il existe sans doute pire).

[Marco46]

C'est quoi la méthodologie Waterfall ? Première fois que je lis/vois/entends ça ...

[nonoxp]

Je sais pas comment on dit en bon français car toujours utilisé ce terme... méthode séquence ? méthode en cascade ?
http://en.wikipedia.org/wiki/Waterfall_model

[Marco46]

Ok donc c'est la méthode d'origine et de base dans le génie logiciel. Des specs vers la maintenance d'un trait et d'un bloc.

[Faiche]

On appelle ça souvent le modèle en V.

[Heziva]

Je sais pas comment on dit en bon français car toujours utilisé ce terme... méthode séquence ? méthode en cascade ?
http://en.wikipedia.org/wiki/Waterfall_model

Cycle en V ?