Last update: 02/06/2016 13:53

Organiser un PSO ne peut se faire que si on lui a imprimé un objectif irréductible. En l'occurrence, cet objectif peut se nourrir du constat de l'existence d'un problème récurrent, souvent rencontré dans maintes sociétés, tous secteurs confondus.

Commençons donc par reconnaître la nature du problème en question qui expose deux facettes :

  1. Les chefs de projet sont dépassés par une quantité impressionnante de tâches administratives[1]
  2. Les responsables de portfolio — voire les chefs de département — sont inondés de détails qui ne leurs fournissent pas l'image d'ensemble dont ils ont besoin

Le PSO doit donc avoir comme double objectif les deux angles de ce problème. Sans égard pour les moyens, nous dirons donc qu'un PSO efficace est celui qui fournit une aide aux chefs de projet et aux responsables portfolio et/ou chefs de départements.

Procédures et guidelines

Nous sommes de ceux qui pensent que procédures et guidelines sont des élémanets indispensables de la bonne organisation de l'IT. C'est via les procédures qu'on peut assurer la mise au point progressive de recettes du succès. Nous ne mettons pas cela en cause, loin s'en faut.

Cependant, on pense souvent que la mise en place de procédures est à elle seule une garantie de succès, et là, on est loin du compte. Toute procédure, plutôt que d'être comprise comme une aide, un guide, est d'abord vécue comme une contrainte inadaptée à la situation propre au chef de projet qui doit s'y soumettre. C'est invariable ... et c'est souvent juste [2] .

Les chefs de projet auront tendance à abandonner les procédures en période tendue, agitée. En période sereine, ils n'ont pas nécessairement envie de les suivre, mais ils s'y soumettent de bonne ou mauvaise grâce. Voilà qui illustre le premier point du problème.

"Too Fined Grained"

Le deuxième pan du problème, le deuxième angle, est la grande disparité de l'information qui est adressée aux responsables de portfolio (et/ou, nous le répétons, aux chefs de département). Cette disparité trouve toute son essence dans les détails, l'information trop finement moulue, qui leur est donnée. On se perd souvent dans les détails. Or, ce dont ils ont besoin est excessivement simple: il s'agit de la même information que celle qui est mise en avant dans un "Steering Committee" (Sponsorship Meeting), à savoir:

  1. Le progrès enregistré par rapport au progrès attendu selon un double point de vue :
    1. La ligne de temps
    2. Les produits attendus (délivrables ou encore milestones)
  2. La situation budgétaire, selon 5 angles :
    1. Le budget alloué
    2. Le budget dont on pense avoir besoin jusqu'à la fin du projet
    3. Le budget déjà dépensé
    4. Le budget disponible
    5. La consommation moyenne
  3. Les ressources
  4. Les risques et problèmes (Risks & Issues)
  5. Les plans mis au point pour la phase qui suit

Rien de plus, rien de moins, mais malheureusement c'est rarement le cas. Le plus souvent, l'info principale est dispersée dans des détails qui détournent l'attention.

Le contenu pose donc (souvent) problème mais ce n'est pas le seul écueil. En effet, d'autres trublions entrent en lice :

C'est à l'ensemble de ces problèmes que doit répondre le PSO, dans le cadre de procédures et de standards pré-établis [3] .

Tâches du PSO

Sans plus de littérature, voici une liste des tâches du PSO [4] :

Il est important de constater que toutes ces démarches sont des préparations de données à l'intention des PM. Ensuite, les PM devront se charger de transformer ces données en informations. Par exemple, d'une simple donnée budgétaire, le PM sera amené à tirer une conclusion : budget alloué 400mdays (donnée), budget consommé 300mdays (donnée), progrès enregistré 70% (donnée), conclusion : project is behind schedule (information).

Taille de l'équipe PSO

L'ensemble des tâches du PSO représente environ 1 journée à 1 ½ journée de travail par projet mensuellement car la charge de travail est relativement constante [6] . On en concluera aisément qu'une personne au PSO peut s'occuper d'une vingtaine de projets (c'est un ordre de grandeur et non un chiffre précis). Dès que l'équipe PSO dépasse 1 personne, il est souhaitable de lui adjoindre un chef d'équipe. On passe donc rapidement d'une personne à trois personnes.

Financement du PSO

Le PSO s'inscrit dans le cadre du Project Delivery (voir notre article Établir le budget d'un département IT). Il en découle qu'il est à sa charge. Le PSO est mis en place pour tous les types de projet, tant les projets purement IT que les projets Business. Quant à savoir qui doit payer pour ce genre de service et donc savoir à quel budget émarge le charge PSO nous n'avons pas trouvé de méthode plus simple que de reporter la charge du PSO dans les budgets des projets, par exemple à raison de 1 journée par mois [7] . Ne faites pas l'erreur d'appliquer un ratio PSO sur base du budget global d'un projet. Le PSO est affaire de coût fixe (ou quasiment).

La conséquence de notre proposition est que le PSO ne côute finalement rien au département informatique [8] puisqu'il est englobé dans le coût des projets et, à ce titre, fait l'objet d'un financement par le Business. Que le coût du PSO soit ou non inclus dans l'effort de supervision que vous prévoyez pour chaque projet est finalement affaire de convention. De notre côté nous avons pris l'habitude de conseiller que ce coût soit compté en sus de l'effort de supervision, mais … nous n'en faisons pas une religion.

Notes de bas de page

[1] … L'utilité des tâches administratives auxquelles les chefs de projet doivent s'astreindre n'est pas mise en question. Le constat est seulement fait qu'elles sont nombreuses et que le chef de projet se fait souvent dépasser, doubler par elles. Il a alors l'impression de négliger l'important pour l'accessoire.

[2] … Pour que les procédures soient adaptées à de multiples situations, à des contextes variés, elles doivent évoluer, faire l'objet d'une révision, d'amendements, etc. Bref, les procédures doivent vivre, s'adapter ou … mourir. C'est l'essence même de CMMI.

[3] … Ce n'est pas au PSO de fournir procédures, standards et guidelines. Cela c'est la tâche d'un département 'Méthodo' ou d'un PMO, Project Management Office. Cela ne fait pas l'objet de cet article.

[4] … L'hypothèse est faite que les Status Reports doivent être établis mensuellement. La fin du mois est notée par "M". M-4 veut dire, 4 jours ouvrables avant la fin du mois.

[5] … Project Manager

[6] … Le travail du PSO est relativement constant de projet à projet : les effets de taille sont peu concernés. Peu concernés ne veut cependant pas dire "négligeables dans tous les cas". Il vous appartient de juger en fonction des cas que vous rencontrez. Par ailleurs, un projet composé de projets a une charge PSO égale au nombre de projets + 1 x nombre de jours que vous décidez d'allouer.

[7] … Tout mois entamé devrait donner la même charge de travail pour le PSO, même si c'est pour un ou deux jours. En effet, tant que le projet n'est pas clôturé, il doit faire l'objet de rapports.

[8] … Pas tout à fait vrai parce que le PSO est aussi répercuté dans le coût des projets purement IT.

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X