1. Services|
2. Références|
3. Articles|
4. Didacticiels|
5. Ressources|
6. Jobs|
7. Contact|
8. Termes|
9. Aide|
10. Sitemap|

Nos autres articles

Organiser un Project Support Office

gestion de projet,project management,project support office,pso

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 :

• le format dans lequel les informations sont véhiculées
• la fréquence à laquelle les infos sont publiées
• la langue dans laquelle les infos sont rédigées
• ...

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] :

• Préparer les situations budgétaires des projets (info à soumettre aux PM^[5] ) : M - 4
• Préparation des "Risks et Issues" depuis le log" départemental (extraction par projet)
• Compilation des problèmes de ressources (niveau départemental avec mise en évidence des ressources sur lesquelles des problèmes subsistent, et ce, par projet)
• S'assurer que les Status Reports soient soumis par les PM à M-1 dans la dernière version du format standard, dans la langue convenue (en anglais le plus souvent)
• S'assurer que les "Risks and Issues" dont les dates d'action sont dépassées aient été traités (si "clôturés", une raison de clôture doit être mentionnée)
• S'assurer que les délivrables standards correspondant au Project Life Cycle soient disponibles (documents d'initiation, documents d'architecture, project plan, analyses, risk log, test cases, ...)
• S'assurer que les délivrables qui nécessitent un sign-off ont bel et bien été approuvés
• S'assurer que les projets hors schedule ou hors budget, s'ils ont atteint les bornes de déviance (x%), fassent l'objet d'Exception Reports
• S'assurer que les projets soient clôturés (après LIVE date)
• S'assurer que les projets soient proposés en mode Service Delivery (établissement d'une liste de projets candidats)
• Rassembler les métriques
• Identifier les projets qui ont des problèmes éventuels de ressources
• Compiler l'ensemble des SR de tous les PM (habituellement sous la forme d'un cahier mensuel) et les soumettre aux Portfolios Managers et/ou Chefs de départements. La compilation est datée. Chaque projet possède un RAG status (Red, Amber Green). Les projets qui ne sont pas "Green" sont clairement identifiés
• Compiler les "Risk and Issue" logs de tous les projets et les soumettre aux Portfolios Managers et/ou Chefs de départements. La compilation est datée.
• Compiler les "Exception Reports". La compilation est datée.
• Oraganiser les entrevues entre les PM et les Portfolio Managers et/ou chefs de départements pour tous les projets qui doivent faire l'objet d'une révision. D'office les projets qui sont "Red" ou qui ont des "Risks and Issues" de type High ou Critical font l'objet d'une revue.
• Archivage des compilations à M + 4.
• Mise à jour des métriques à M + 5.

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 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.