Problmatique de la structure matricielle de projets
Daniel Leroy
Matre de confrences lI.A.E. de Lille
Directeur du DESS Gestion de Projets
FICHE TECHNIQUE: LES PROBLEMES ORGANISATIONNELS LIES AUX
STRUCTURES REALISANT DES PROJETS
Principe: il est ncessaire de placer la conduite du projet sous
une autorit unique et indpendante des hirarchies qui le ralisent:la
structure matricielle dfinit la relation entre le chef de projet
qui prend le statut de client et les services excutants qui doivent
tre considrs comme des fournisseurs.
( Gnralement, les objectifs des services de lentreprise et ceux
du projet sont concurrents et souvent contradictoires, do des cas
graves de DYSFONCTIONNEMENTS...(
Abus de pouvoir dun chef de service sur le projet
Un premier cas de dysfonctionnement concerne les manipulations
budgtaires faites aux dpens du projet par les responsables de
service: parfois sur les directives du directeur gnral, ou bien mme
de sa propre initiative, un responsable dont le service excute des
paquets de tches pour plusieurs projets dcide dutiliser le budget
qui lui a t allou pour un projet, pour les besoins urgents dun
autre projet, lui, en retard. Sil se trouve quun service, un niveau
assez global de lorganigramme hirarchique, ralise plusieurs
projets, ou compltement ou en grande partie, un arbitrage se cre
ainsi tout naturellement, indpendamment des objectifs de chaque
projet.
Des manipulations encore plus gnantes peuvent tre faites: en
dpassement de dpenses sur les travaux dun projet, et au large sur
un autre, certains responsables de service trouvent intrt, au sens
de leur objectif propre, imputer les factures du projet dans la gne
sur le budget du projet, plus riche. De tels transferts de
codification, rpondant aux besoins immdiats dquilibre des budgets
de service, surviennent malheureusement souvent, aux dpens des
projets; toute crdibilit et toute possibilit de contrle sont ainsi
retires au projet, il ny a plus de gestion mais simplement de la
comptabilit.
2. Un chef de projet favorise le service auquel il appartient,
aux dpens de son projet.
Le manque dautonomie et de pouvoir rel dun chef de projet,
lorsquil reste sous lautorit dun chef de service, le conduit donner
des gages vis--vis de son chef de service; il est alors tent de
favoriser lavancement du travail sous-trait son service, quitte
retarder les tches sous-traites aux autres. Si par exemple une
conomie sur le budget total du projet, dont il a la charge doit tre
faite, il essaiera de la trouver sur les tches des autres services;
il pourra pour cela en modifier certaines spcifications (il le faut
dira-t-il), ou retarder certains vnements de leur planning. Son
intrt personnel, carrire, avancement ou mme simplement de la
prudence, le porte ainsi viser les objectifs internes du service et
non les objectifs du projet qui devraient pourtant, pour lui, avoir
la priorit.
3. Le technicien excutant ne voit pas plus loin que sa propre
tche et ignore laspect systme du projet.
Il est tout fait vrai que le technicien dun service qui a t
sous-trait un paquet de tches (paquet de lO.T.) possde la comptence
pour le travail demand. Les spcifications sont en gnral dailleurs
assez compltes et prcises, et lexcution doit sy tenir. Mais dans
les projets, de nombreuses incertitudes restant encore lever, les
spcifications visent les performances obtenir et non plus les
moyens spcifiques dy arriver. Il reste donc de nombreuses
initiatives voire modifications dcider pour un travail sous-trait;
cest dans la nature mme des projets.
Et lon soulve l une question importante pour le projet: le
technicien peut-il prendre des initiatives dont il est capable,
dailleurs? Cela parat aller de soi puisque les spcifications sont
respectes? Mais lon sait que le projet est souvent un systme
complexe; chacune de ses parties est lie fonctionnellement,
physiquement, aux autres parties; il nest pas toujours possible de
savoir jusqu quel niveau de dtail cette interdpendance technique a
de limportance. Si bien que le choix dune technologie, dun produit,
de la matire constituant une simple rondelle, peut entraner des
consquences imprvues sur lensemble du fonctionnement du projet.
Pourtant ne rendant compte qu sa propre hirarchie, le technicien
prendra ses dcisions avec dautant plus de certitude quil est
comptent. Le projet ny trouve pas toujours son compte.
4. La multiplicit des services hirarchiques sous-traitants rend
toute coordination impossible.
Si le projet, assez complexe et vaste, est ralis par un grand
nombre de services dans lentreprise, on rencontrera de nombreux cas
dinterdpendances techniques: telle tche ne pourra tre dfinitivement
dfinie que lorsque telle autre tche aura t ralise, aprs tel essai.
Lallocation des paquets dorganigramme technique des services
sous-traitants ne dtermine pas les relations ncessaires entre
tches. Il faut mettre en rapport les diffrents techniciens, qui
doivent travailler en quipe. Or, si ces techniciens sont dans des
services diffrents et lointains, leur coordination devient une
coordination entre leurs chefs, puis finalement entre les chefs de
ces chefs... problmes de suprmatie, de comptences techniques, et
mme l encore, dintrts budgtaires de services, sont alors
perptuellement soulevs. Larbitrage ne peut que remonter au plus
haut niveau, cest--dire tre fait arbitrairement si des tudes
prcises et compltes doptimisation ne sont pas faites. On voit
peut-tre sans trop dinconvnients un directeur gnral prendre en main
la gestion, ou plutt la direction dun projet, sil ny a quun projet
qui reprsente un objectif fondamental pour lentreprise; on voit
mal, par contre, comment il ferait sil y avait plusieurs projets
ncessitant des dcisions frquentes en raison de leur technicit de
pointe.
( Lparpillement dun projet sur lorganigramme de lentreprise pose
de gros problmes de coordination: on ne peut envisager de donner un
chef de service en particulier le rle de diriger les travaux
dautres services, sous peine de conflits graves et
inextricables.
Pourquoi y a-t-il concurrence dintrts entre projet et services
?
Bien que le projet comme le service aient pour objectif final le
dveloppement de lentreprise, en particulier son bon fonctionnement
financier, on constate que les chemins quil faut prendre pour
latteindre sont diffrents: le cot des heures et lemploi du temps du
personnel dun service aboutissent par sommation des recettes et des
dpenses qui laissent plus ou moins de marges. Ces marges mnent, si
la gestion de lactivit du personnel et des machines est bien mene,
un profit pour lentreprise; pour un projet, la russite nest sre qu
son achvement, car elle dpend dune part, des carts entre ce qui
tait prvu lorigine et ce qui est ralis peu peu jusqu la fin, carts
jugs en recettes et dpenses il est vrai; mais cette russite dpend
aussi du rsultat physique des performances obtenues: un satellite
qui ne fournit pas la performance attendue par le client devient
une grosse perte financire; un projet comme le tunnel sous la
Manche, sil ncessite avant quon le livre lutilisateur, de trop
nombreux amnagements non prvus, payer par le matre de louvrage et
le matre doeuvre, devient un gouffre financier.
Lobjet du projet est donc, indpendamment de la satisfaction
budgtaire des services qui le ralisent, sa REUSSITE. Cette russite,
seulement si elle est acquise, apporte bnfice lentreprise. A tel
point quun projet qui aurait permis aux services sous-traitants de
faire des marges confortables pour leur objectif annuel, mais qui
aboutirait un dpassement norme de son budget, ou un glissement de
sa date dachvement, ou encore un produit sous-performant, serait un
chec reconnu par tous et surtout par le client: situation
paradoxale puisque les chefs de service seraient contents davoir
fait leurs marges, mais le client, qui diffusera plus tard limage
de lentreprise, lui fera le plus grand tort.
( Intrts des services, vus court terme, et intrt du projet, qui
ne peut tre vu qu long terme, sont, en pratique, opposs.
1. Du point de vue budgtaire
Les cas de dysfonctionnements voqus au dbut de cette fiche
technique sont aisment explicables si lon comprend bien les
objectifs des chefs de service et si on les compare ceux du projet;
ils sont totalement diffrents en terme dactivits quotidiennes: le
but du chef de service est la marge; ce qui nexclut pas la qualit
du travail ralis, mais mme pour cette qualit, cest encore la marge
lojectif final. Quel que soit le systme de gestion de lentreprise,
atteindre lobjectif fix et mme faire un peu mieux, est lambition du
chef de service. Tout est fait pour optimiser ce critre: maximiser
la marge.
Lorsque tout responsable se trouve devant un choix technique, il
obit cette rgle de la marge du service; cela explique les pratiques
voques dans le premier paragraphe: que le chef de projet soit
volontaire et dcid russir son projet ou non, il ne peut que
trancher dans ses alternatives pour les solutions favorables au
budget du service dans lequel il est subordonn; dans le cas
contraire, sil donne la prfrence au projet quen principe il doit
conduire, il est en contradiction flagrante avec les rgles de bonne
conduite du service.
Cette obissance aux exigences budgtaires du service peut
videmment conduire le chef de service rpartir les imputations au
mieux, manipuler les codes entre projets; elle peut conduire un
chef de projet subordonn un service maximiser les marges pour son
service, mme si le rsultat mne une dgradation du projet: cherchez
qui le juge!
2. Du point de vue des plannings
On se trouve devant la mme situation; certes le (ou les) projets
dont il a sous-trait une part font partie des objectifs du chef de
service. Mais les contraintes des plannings, des plans de charge,
et loptimisation de ces contraintes sur le critre de la marge et du
budget final annuel, sont les rgles de fonctionnement dune
entreprise. Le succs dun projet nest pas pour lui dun intrt
suprieur ceux-l.
Pour le service, lordre des oprations, quelles soient de srie ou
par units, est optimis sur les moyens en matriel et en personnel.
Pour le projet, lensemble des activits est planifi aprs un calcul
PERT ou quivalent, uniquement partir des tches du projet.
Il ny a, a priori, aucun point commun ou point daccord entre les
planifications du projet et celles des services fournisseurs. Ce ne
peut tre que par ngociation quune entente et finalement un ordre de
lancement des tches peuvent tre obtenus. Ds que lun ou lautre, le
chef de projet ou le chef dun service a la prpondrance, le projet,
ou le service est dsorganis. La position dun responsable projet
dans un service, dont le rle serait de dfendre et optimiser au sens
du projet, les dures et dates de lancement des tches du projet,
nest pas tenable.
3. Du point de vue technique
Chaque service est propritaire de son savoir-faire, de ses
moyens, de ses mthodes, acquis par des annes de fonctionnement; il
est, on la vu, tenu par des objectifs financiers. Son rle est de
surveiller et maintenir lquilibre de ces paramtres. De plus, il
existe dans un service des habitudes qui font partie de son mode de
vie.
Il est parfaitement comprhensible que lexcution dun travail,
bien que contrainte par des spcifications, laisse des initiatives
nombreuses quant aux mthodes; cest mme souvent une condition du
progrs.
Il arrive cependant que grce son savoir-faire le technicien
ayant pris en main un paquet de tches dun projet veuille sy prendre
sa faon. Ce peut tre un avantage, mais ce peut tre aussi dramatique
pour un systme/projet. L encore les exigences venant dun projet,
devraient tre prioritaires par rapport celles qui viennent du
service sous-traitant. Il ny a pas identit dintrt entre ce que
voudrait faire un service fournissant un travail et ce que voudrait
obtenir le client; si par bonheur les spcifications suffisent viter
les problmes ultrieurs de nature systme dun projet, le
laisser-aller nest pas grave; mais dans la plupart des cas, des
corrections doivent tre apportes par le projet-client: on retrouve
encore le problme de lautorit prioritaire sur les activits projet:
il faut garder en mmoire le problme de la rondelle, choisie par le
technicien sous-traitant parce quil en a en stock ou parce quil en
a en stock ou parce que cest plus facile utiliser alors que le
matriau est tout fait contraire la qualit et aux performances du
systme entier; le technicien ne peut le savoir; la spcification
pourtant prcisait bien la nature du matriau, mais pour le
technicien, ses problmes de service primaient sur des spcifs trop
tatillonnes exiges par le projet. Cette dsobissance mineure a
failli mener un projet connu lchec.
Malgr tous les essais et efforts, les structures classiques nont
jamais pu concilier objectifs services et objectifs projets. Les
tentatives de faire entrer le projet dans la structure classique
nont pas abouti et cest un type de relation tout fait nouveau quon
a fait appel: la structure matricielle.
Un premier pas vers la solution: la reconnaissance dune identit
projet autonome et la cration dune responsabilit complte et
indpendante sur sa conduite.
A partir du moment o est reconnue la ncessit de tout faire pour
quun projet soit men bon terme, la russite de cet objectif final
prsentant le mme intrt que la russite des gestions des services de
lentreprise, une premire condition apparat vidente: il faut sortir
le projet de sa dpendance vis--vis de ceux qui nen ralisent que des
morceaux, et reconnatre son identit propre.
Cette identit projet est dautant plus naturelle quon aura
compris, dune part, limportance dune bonne et dfinitive dfinition
de ses missions (les premires phases, aboutissant aprs lanalyse
fonctionnelle, un premier cahier des charges), et dautre part les
consquences de lOrganigramme Technique: le projet est bien un tout,
dont les morceaux (les paquets de tches de lO.T.), bien que
rpartis, parpills mme, dans les services trs divers, doivent tre
continuellement regroups, maintenus cohrents puisquils constituent
un systme.
Seule une responsabilit globale, unique et indpendante peut
maintenir lindpendance du systme ainsi reconnu. Toutes les
dysfonctions dcrites dans les pages prcdentes disparaissent si lon
donne un vrai responsable du projet le rle de traiter les problmes
du projet: le budget du projet appartient au projet; les paquets de
tches, comme lO.T. le permet, ont leur dotation en budget;
lallocation de chacun de ces paquets de tches des services qui les
excuteront est en consquence assortie de son budget: le service
sous-traitant a ce budget, ni plus, ni moins. Le responsable du
projet est propritaire des budgets de chacun de ces paquets, et
comme tout propritaire, seul habilit des modifications de leurs
montants: quelques dysfonctionnements disparaissent.
Le responsable du projet, son propritaire est, responsable de
laboutissement du projet la date prvue, donc responsable de toutes
modifications de planning ayant des consquences sur le droulement
du projet. Enfin, gardien svre des missions donnes au projet ds son
lancement, le responsable du projet est seul responsable des
modifications techniques (caractristiques, performances) proposes
pour les tches sous-traites.
Ce premier pas tait le seul possible ds quon avait compris que
les structures classiques mlangeaient objectifs projet et objectif
excution. Le premier principe qui a dclench la fonction projet fut
historiquement nonc ainsi:
- Cration dune fonction de responsable complet: chef du projet,
directeur du programme, etc. (peu importe la dnomination,
limportant tant ce que contient la fiche de fonction, cest--dire le
pouvoir);
- Dlgation de la responsabilit du succs daboutissement du
projet;
- Droit normal linformation sur le droulement cots, dlais,
technique des paquets de tches sous-traits;
- Droit dcisions cots, dlai, technique, lorsque les
spcifications concernant les paquets de tches sous-traits sont en
cause;
- Droit et devoir de gestion du projet, impliquant documents
dinformation, moyens de gestion, sans exclusive, avec pour
consquence la constitution dun tableau de bord spcifique au
projet;
- Indpendance de cette responsabilit vis--vis des services
sous-traitants, tempre cependant par:
* une intgration du projet dans la stratgie de lentreprise au
mme niveau que les productions des services oprationnels,
* une obligation darbitrage au niveau stratgique, lors des
conflits possibles entre intrts de service et de projet.
Cette rvolution de structure, ncessaire pour la rsolution des
problmes de conduite de projet, apportant un nouveau type de
responsabilit et, avec, son nouveau type de relations dans
lentreprise na t accepte et mene bien (ou presque...) que peu peu.
Elle conduit, il est vrai, de nouveaux types de conflits, puisque
engendrant un nouveau type de relations: toute structure, partir du
moment o elle dfinit des pouvoirs, gnre ses difficults; ce fut le
cas de la direction par objectifs, et dautres encore; limportant
est de bien identifier la nature de ces conflits possibles.
(La structure matricielle et la relation client-fournisseur
entre projet et services apportent une solution intressante.
La nouvelle position du projet lextrieur des structures
oprationnelles et la dfinition dune responsabilit complte et unique
sur la conduite ncessitent une clarification dun certain nombre de
consquences sur la gestion et le partage des responsabilits.
1. Du point de vue des structures,
la relation est non seulement simplifie, mais encore rendue
possible par lexistence de lO.T. Chaque paquet de lO.T. est allou
pour ralisation un service de lorganigramme de lentreprise. Le
tableau de correspondance entre O.T. et organigramme de lentreprise
est appel matrice et la structure correspondante structure
matricielle.
- chaque paquet de lO.T. sera allou un responsable et un
seul;
- plusieurs paquets peuvent tre allous un seul service (sils
sont bien identifis);
- plusieurs services ne pourront pas se partager un paquet de
lO.T. (il faut si la situation se prsente, scinder le paquet ).
2. Du point de vue des partages de pouvoir,
On retrouve deux pouvoirs:
- le pouvoir hirarchique classique, dont le pouvoir (et le
devoir) est de faire fonctionner les services, dans le cadre de la
politique de lentreprise (services dots dun budget, de mthodes et
de savoir-faire, de programmes et de plans de charge, etc.);
- le pouvoir du chef de projet, dont la mission est de mener son
projet bien, en en dlguant les morceaux aux services
hirarchiques.
Le chef de projet fait faire, le chef de service fait.
Le chef de projet sappuie sur les spcifications du projet,
indpendantes en gnral des moyens existants pour les obtenir, le
chef de service sappuie sur ses moyens et son savior-faire, prts
autant que possible satisfaire ce que le projet exige.
La seule dfinition de relation qui convienne et puisse
sapparenter une relation dj vcue dans le milieu industriel est la
relation client-fournisseur. Le pouvoir du chef de projet est celui
du client, le pouvoir du chef de service est celui du
fournisseur.
3. Du point de vue dcisionnel,
Il suffit (ou presque) dappliquer la loi empirique
client-fournisseur: le client passe commande, le fournisseur
ralise. Sagissant de projet, cest--dire de produit, de tches
soumises des alas, donc pouvant ncessiter des retours en arrire
quant leur dfinition, le contrat pass entre client et fournisseur
ne peut se passer de clauses de contrle, de clauses de gestion.
Sans pour autant empiter sur le pouvoir du service, il est vident
que le chef de projet-client ne peut viter:
- de sinformer sur lavancement des travaux,
- de sinformer sur les carts constats ou prvus du point de vue
cots, dlais, technique,
- dintervenir pour dcider lui-mme des modifications acceptables,
aprs analyse des interfaces avec les autres parties de son
projet.
Ces deux parties contractantes (on peut employer ce terme, bien
que lon nait pas tout fait quivalence avec les contrats dentreprise
entreprise extrieure; on parle parfois de quasi-contrats, terme qui
dcrit bien la situation) peuvent se trouver en conflit, leurs
intrts divergeant parfois (les problmes de fond voqus au dbut de
cette fiche restant videmment) une procdure darbitrage doit tre
dans tous les cas prvue, de faon que ni les uns ni les autres ne
soient lss, lobjectif final tant de toute faon la mission de
lentreprise.
Que contient cette relation client/fournisseur? La rponse est
tout fait conforme aux pratiques classiques: le client fixe ce quil
veut (les spcifications cela de faon plus ou moins prcise, et tous
les points de vue cots-dlais-technique); en tant que client, il
demande, exige mais aussi ngocie car tout nest pas forcment
possible pour son fournisseur (en particulier cause de son plan de
charge ou de ses cots internes). Celui qui ralise les travaux aprs
ngociation, excute aux conditions prvues dans le contrat. Les
pratiques classiques sappliquent dans cette relation entre
responsables de paquets de lO.T.: certains contrats sont globaux et
forfaitaires parce que le client sait bien ce quil veut, dautres
sont plus incertains et comprennent un dveloppement de travaux
longs et difficiles avec parfois des options et mme des dcisions
prendre en cours de route. dans ce dernier cas, il est vident que
le client demandera au fournisseur quil le tienne au courant de
lavancement des travaux ( tous les points de vue
cots-dlais-technique), ce qui conduira de la part du client une
sorte de contrle sur le fournisseur.
4. Du point de vue information et gestion,
les droits et devoirs du chef de projet exigent de lui quil ait
son propre tableau de bord, et pour cela un circuit dapport des
informations propre son projet. Chaque paquet dO.T. doit contenir,
pour quon en ait une gestion cohrente intgre lensemble des
informations cot, dlai, technique concernant les ralisations comme
les prvisions. La relation projet-services, en pratique la matrice,
est donc tout naturellement le support pour la circulation des
informations.
( Pour permettre des ractions rapides aux vnements et alas qui
surviennent, le circuit O.T. qui passe directement par les
responsables projet (suivant la relation client/fournisseur) doit
imprativement tre suivi.
( Pour regrouper les cots, les dpenses pour tout ce qui concerne
le fonctionnement des services suivant une structure pyramidale
hirarchique, lorganigramme classique convient.
La consquence pour les responsables projet (chefs de
sous-projet, cest--dire de plusieurs paquets de lots de travaux
parpills dans plusieurs services) est la suivante:
- un responsable projet est pour ce qui concerne la vie dans le
service, son fonctionnement, le respect de ses rgles internes,
lemploi des matriels, attach hirarchiquement au chef de
service;
- pour ce qui concerne le dveloppement des travaux raliss pour
un projet, il suit les directives propres au projet (spcifications,
cots, etc.). Il est directement en relation avec son client qui se
trouve tre gnralement un autre responsable projet dun autre service
et en relation avec ses fournisseurs qui peuvent aussi tre des gens
de son mme service que des gens dautres services ou mme dentreprise
extrieures.
Dfinition des dlgations donnes aux responsables et chefs de
projet, excutants des tches et chefs de services
1. La dlgation - La responsabilit
Plac en position de client vis--vis des excutants et services
qui ralisent les tches et paquets dorganigramme technique, le chef
de projet comme les responsables projet, doit faire faire le
travail. Cette position particulire due la structure matricielle
semble ajouter une difficult nouvelle dans les relations dans
lentreprise. Pourtant, faire faire est aussi un problme dans toute
la structure; il nest donc pas nouveau.
Les diffrences entre les faons possibles de faire faire tiennent
plus des questions de forme qu des questions de fond: obtenir quun
travail soit excut correctement et mme au mieux dpend la fois du
pouvoir quon a sur lexcutant, et de la manire dont la demande (ou
lordre) a t faite et reue. Le bon fonctionnement de la relation
client/fournisseur est encore plus li cette faon de faire faire
quil ne lest pour la hirarchie; mais il lest dj fortement pour
celle-ci, car cest un problme naturel de direction: il sagit de la
dlgation.
Quoi faire est la mission donne, lobjectif: les spcifications du
travail faire sont prcises, obligatoires, donc imposes. Elles
peuvent tre plus ou moins dtailles mais quoi quon fasse, elles ne
peuvent jamais tre compltes et suffisantes. Il faut souvent
interprter les directives, adapter les mthodes et mme amliorer les
performances si cest souhaitable et possible, bien que non prvu:
comment faire laisse toujours des latitudes.
Comment faire est la partie libre, plus ou moins riche en
initiatives, dun travail faire.
Dlguer, cest fixer aprs ngociation un cadre dobjectifs, une
mission, en laissant libres des initiatives pour aboutir.
Chacun peut en tmoigner: si lon y fait attention de nombreuses
tches peuvent tre dlgues alors quon les excute trop souvent
soi-mme. La difficult qui existe vraiment est de deux ordres:
- dune part, il faut savoir bien ce que lon veut: dfinir les
objectifs, la mission;
- dautre part, il faut accepter que les moyens employs, la
manire, soient diffrents de ce quon ferait soi-mme (ou alors cela
signifie quon aurait d inclure les variantes dans les
objectifs).
La dlgation est une prise de conscience difficile mais
ncessaire, car elle fait gagner du temps, redistribue et utilise
les potentiels de comptences.
Mais dlguer nest pas tout: il faut que la tche dlgue soit
effectivement ralise; et correctement, conformment aux objectifs.
Cela, partir du moment o on a dlgu, nest plus du rle de celui qui
dlgue: on a laiss linitiative. Et pourtant, puisquun rsultat doit
tre obtenu conformment aux objectifs, il faut sen assurer, le
contrler. Et si le rsultat nest pas correct, la faute est celle de
lexcutant qui on la dlgu: il est rendu responsable.
Pour quune dlgation ne reste pas une simple manifestation de
laxisme inconscient, il faut donc quelle comporte en complment:
- Des critres de jugement sur les rsultats obtenus: est-ce bien
ce quon a demand?
- Un jugement effectif: sur ces critres car il ne sagit pas de
reprocher ce qui na pas t demand dans les spcifications, et non
prvu. Le jugement de russite doit tre port effectivement et
prcisment sur les critres tablis et reconnus, accepts par le
dlgataire et le dlgu.
- Et enfin, car il faut y passer, une sanction doit tre prvue
dans tous les cas (positive et agrable, ou ngative et
rpressive).
Lensemble de la dlgation, des critres de jugement de laction, du
jugement, de la sanction constitue une responsabilit.
2. Le chef de projet, le responsable projet
La dlgation donne un chef de projet est tout fait claire et
simple: il faut russir le projet ou le paquet de lO.T.
sous-trait.
3. Le chef de service
Le chef de service, qui un quasi-contrat a t allou (ngoci) par
le projet, se trouve dans une position stable et solide dans la
hirarchie, possdant les moyens et la manire de raliser les travaux.
La dlgation quon lui a donne (son chef un niveau suprieur, la
direction gnrale, le conseil dadministration, etc.) est une
dlgation de chef dentreprise: le service est une petite entreprise
lintrieur de la pyramide plus vaste, et la dlgation consiste la
faire fonctionner au mieux. Les contraintes et les limites de cette
dlgation sont son interdpendance avec les autres services, qui avec
lui constituent lentreprise dans son ensemble. Si bien que la
dlgation donne ce chef de service, ne peut tre modifie, entame que
par cette organisation hirarchique suprieure, selon ses objectifs.
Et les rgles, les pouvoirs que constitue cette dlgation, ce que
contient le cadre de dlgation du chef de service, ne peuvent tre
transgresss ni par un subordonn, ni par un responsable ou un chef
de projet extrieur.
Que contient prcisment cette dlgation ?
Tout dabord, un budget fix (plus ou moins ngoci et souple) que
le service financier et le contrle de gestion vrifient. Ensuite,
dans lenveloppe de ce budget (annuel ou sur plusieurs annes), les
quipements existants doivent tre entretenus, renouvels et certains
investissements doivent tre faits.
Pour raliser les travaux que le service est capable de faire,
les contrats pour lesquels il sengage, il faut du personnel, donc
le choisir et le recruter, puis rpartir ses tches en quilibrant les
plans de charge sous la forme de programmes.
Enfin, pour un fonctionnement harmonieux jusqu long terme, la
formation du personnel, la conservation du savoir-faire des quipes
et la prservation de la documentation, la bonne entente dans les
relations internes, font partie des charges importantes du
responsable hirarchique.
A lintrieur de ce cadre, le chef de service optimise et quilibre
son action et, son tour, dlgue au niveau subordonn en dessous.
4. Lexcutant dune tche
Faisant partie dun service, le technicien ou lingnieur, quon
appelle ici excutant dune tche, relativement au projet, ralise les
travaux et tudes du service, sous lautorit du chef de service. Tout
naturellement, la dlgation jouera entre excutant et chef de
service, quelle que soit la nature des travaux. Cette dlgation sera
plus ou moins large, selon les spcifications techniques de dlais ou
de cots, mais une direction bien comprise comportera le plus
dinitiatives possibles.
Pour ce qui concerne le projet, lexcutant a pour rle de raliser
une tche qui peut tre une partie dun paquet de lO.T. ou un paquet
de lO.T. entier. La dfinition de la dlgation sapplique compltement
comme pour tout responsable. Le cadre de dlgation comprend:
- la russite de la tche;
- lutilisation des moyens du service;
- la tenue de son planning et le contrle de ses interfaces avec
les autres responsables, sachant que la coordination de ces
interfaces est videmment du ressort du chef de service;
- le respect des spcifications cots-dlais-technique relatives
aux tches du projet.
Enfin, mais il sagit alors de la partie initiative, il faut
optimiser les conditions dexcution, apporter les amliorations,
recherches et dcouvertes utiles, proposer les solutions aux
problmes rencontrs.
5. Fonctionnement des relations dans le trio: responsable
projet-chef de service-excutant
De nombreuses suspicions de sape de la hirarchie sont nes, ds
lapparition de cette notion de matrice client/fournisseur dans les
premires tentatives dimplantation de gestion par projets. Il faut
dire que ce nouveau pouvoir entrait directement en concurrence avec
le pouvoir de la hirarchie et quen labsence danalyses concrtes des
relations relles dans la pyramide chacun pouvait croire quil tait
plus important ou utile que lautre.
Il faut dire aussi que les uns comme les autres, croyant quil
tait question de bouleverser la nature des autorits, nont pas, dans
les dbuts de la gestion par projets, calm les inquitudes.
Or, comme on vient de le voir en analysant ce que contient la
notion de dlgation, les responsabilits projet et service
hirarchique sont fondamentalement diffrentes, autant utiles et
ncessaires lune que lautre sans aucune considration de niveau
dimportance: dans un systme, quelle partie est-elle la plus
importante ?
Dans la ralisation dune tche par un excutant dun service, la
nature du travail et des relations varie beaucoup entre son
dmarrage et son achvement, et lon peut voir que les dlgations, les
responsabilits, les pouvoirs changent de main chaque instant: il
faut analyser le fonctionnement de la cellule responsable
projet-excutant-chef de service dans son aspect dynamique.
1) La tche dfinie par un paquet de lO.T. est ngocie par le
responsable projet charg du paquet de niveau suprieur dans
lorganigramme technique. Il sagit bien dune ngociation, car il faut
sassurer que le service est capable de raliser le travail, quil
peut le faire dans les conditions demandes par le projet, que son
plan de charge est compatible, etc. Si le service nest pas en
mesure de faire le travail, il faut absolument que cela soit
clairement exprim, car aprs tous les essais et simulations tents
par le chef de projet pour prendre en compte les vues du service,
il doit finalement tre averti temps, sil lui faut passer contrat un
autre service voire lextrieur de lentreprise, si les conditions
imposes ne conviennent pas au service.
2) Le chef de service nomme un responsable projet qui sera charg
du paquet sous-trait. Cette nomination est une vritable dlgation,
de la mme nature que celle donne un chef de projet, dlgation donne
pour le paquet de lO.T. concern.
3) Simultanment, et de toutes faons en quipe (avec le futur
responsable projet, lexcutant, les autres excutants et services qui
seront concerns), sont attribues les dlgations dexcution. Il est
prfrable de mettre au courant le plus vite possible, les diffrents
acteurs futurs. Jusqu ce moment, seul le chef de service a le
pouvoir dagir car il sagit bien de lorganisation de son service. Le
travail est donc lanc conformment aux spcifications et aux
plannings du projet.
4) Avant dentrer dans la ralisation technique, il est absolument
indispensable que lexcutant en comprenne les objectifs et tous les
dtails.
On sait bien que malgr les meilleures tudes possibles et malgr
les prcisions les plus grandes donnes aux spcifications, on
rencontrera des imprvus (dautant plus quil sagit de projets
nouveaux). une fois consensus acquis entre lexcutant et le
responsable projet, chacun agit alors dans le cadre de sa dlgation.
Le chef de service na plus intervenir, sauf vnement exceptionnel
(phase suivante 8).
5) Le responsable projet est charg de suivre les activits pour
le compte du projet: il est responsable du dveloppement du paquet
de tches que lui a dlgu le chef du service. A ce titre, il doit
pouvoir aller sur le terrain voir o en est le travail, le contrler
mme. les informations systmatiques qui lui sont envoyes par
lexcutant, directement et sans passer par sa hirarchie lorientent
dans son contrle. Sagissant dun contrle systmatique frquent quon
pourrait qualifier de croisire, il doit pouvoir sexercer sans
autorisation du chef de service: les dlgations ont t accordes pour
viter cela. Mais il faut encore et toujours insister sur labsence
de pouvoir hirarchique dans cette relation.
6) Le responsable projet, ayant donc dlgation sur un paquet de
tches de lOT (quon peut assimiler pour lui un petit projet) se
retrouve ainsi responsable globalement pour les trois paramtres
cots-dlais-technique. Exactement de la mme manire et avec les mmes
outils quun chef de projet, il conduira et grera son paquet de
lO.T. Tous les outils, toutes les procdures dcrites dans louvrage
sont applicables, un niveau plus dtaill. Les informations de
gestion ncessaires (tableaux, graphiques) la conduite de projet,
ici, la conduite du petit projet reprsent par le paquet de lO.T.,
doivent donc tre gnres par lexcutant et envoyes directement au
responsable projet. Bien entendu, pour les besoins de gestion et
dorganisation du service, ces informations sont aussi fournies au
chef de service. Mais rien nexige que ces informations soient
prsentes sous la mme forme, par exemple regroupes sous les mmes
codifications: les objectifs de service, des services de la
pyramide diffrent de ceux du projet. Le seul problme est quil ne
faut pas obliger lexcutant parler deux langages, lun, pour le
projet avec des tableaux et graphiques spcifiques, et lautre, pour
lentreprise, avec des comptes rendus sur les mmes sujets, mais
exprims diffremment. Cest un problme de forme, et non de fond:
lobjectif vis ici est laboutissement du projet.
7) 8) 9) Au cours des visites de contrle auprs de lexcutant ou
grce aux informations reues, le responsable de projet peut
constater des anomalies ou peut tre averti lavance que des carts
par rapport aux performances et spcifications du projet sont en
train de se dessiner. Il peut sagir parfois de solutions
technologiques diffrentes ou nouvelles dcides par lexcutant dans le
cadre de sa dlgation, son initiative normale, mais que le
responsable projet, connaissant mieux les interfaces du systme
entier, peut juger nfastes. Dans ces conditions, larbitrage entre
lexcutant et le responsable projet est simple et indiscutable: la
solution retenir doit toujours tre celle qui profite au projet ou
le respecte.
Bien entendu, il reste le prouver, et ce sera tout lart et la
comptence du responsable projet ou bien entendu du chef de projet
si le problme est important au niveau du systme et a d remonter
jusqu lui, de convaincre le spcialiste qui dtient la connaissance
technique.
Dans cette tape de contrle, aprs constatation que des
corrections au travail doivent tre apportes, tant technique que de
cot ou de dlais, le responsable de projet demande ou plutt exige
des modifications. Ces modifications peuvent tre mineuresou
majeures, au sens du fonctionnement du service de lexcutant:
- Si les volutions (majeures) quil faut apporter ont des
consquences sur le fonctionnement du service, elles touchent au
cadre de dlgation du chef de service, et engage sa responsabilit
directe: modification du plan de charge et du programme du service,
ce qui modifiera la rpartition des tches des autres employs du
service, changement dans les mthodes fondamentales dessais ou de
travail, ce qui modifiera le savoir-faire ou les emplois du matriel
voire des investissements ncessaires, etc. dans ces conditions,
seule lautorit du chef de service peut dcider des actions mener: le
responsable de projet et lexcutant du travail (et surtout lui car
il sait le mieux ce quon peut faire ou ne pas faire dans le
service) doivent revoir et rengocier avec le chef de service la
suite des oprations mener. Il sagit, plus ou moins formellement,
dune rengociation du contrat entre service et projet.
- Si les volutions demandes sont mineures et ne changent pas le
fonctionnement du service, donc nentament pas la dlgation du chef
de service, lexcutant peut les accepter sans en rfrer
hirarchiquement. Cette dcision lui appartient videmment car il est
seul connatre les limites aux initiatives quil peut prendre. Bien
entendu, consensus et compromis restent la rgle et, l encore, la
capacit du chef de projet et mme celle dun responsable projet un
degr moins important, devient une des forces principales dans le
droulement des activits. Si cela nest pas le cas, il faut prvoir
des arbitrages, sachant toutefois que lobjectif final dans la
rsolution du conflit reste le projet!
(
(
(
(
(
(
(
6. Circulation des informations et prise des dcisions
Partant dun service ou dun excutant dune tche dun projet (paquet
de lOT ou tche contenue dans ce paquet), les informations prennent
deux directions:
- le service, pour rpondre aux besoins classiques de la gestion
de lentreprise;
- le projet, pour les besoins de conduite. Cette information
nest pas forcment la mme dans les deux sens et peut rsulter dun tri
pour rpondre aux deux besoins;
Il est utile de rappeler le but de ces informations pour la
conduite du projet:il faut pouvoir prendre les dcisions ds que cest
ncessaire. Il faut donc:
- tre inform:
des carts de cots ds quils sont constats et prvus par
lexcution,
des carts de dates dvnements, de dures dexcution des tches,
constats et prvus,
des carts sur les performances, des problmes techniques plus ou
moins graves;
- pouvoir corriger ces carts, ou les accepter et alors les
passer en modifications;
- prparer les runions dcisionnelles aux jalons.
Ces informations circulent dans le rseau des responsabilits
projet puisquelles concernent le projet; cest--dire dans le rseau
de lO.T.; elles circulent entre les responsables projet,
directement, sans passer par un circuit quelconque de la
hirarchie.
Dans le sens remontant, il est bien vident que toutes les
informations dun niveau donn ne transitent pas au niveau suprieur:
il sagira de synthtiser, de rsumer ou de choisir par exemple
quelques vnements cls particuliers choisis parmi les vnements cls
des niveaux infrieurs; cest--dire encore de la somme des cots des
paquets infrieurs et des rsultats importants des essais techniques
ou des problmes les plus critiques dclenchant des tudes interface
ou de systme.De niveau en niveau de lO.T., et de plus en plus
synthtiques, les informations remontent jusquau chef ou directeur
de projet. Il va de soi que le plan de circulation (dans lespace et
dans le temps) est dfini lavance.
Dans le sens descendant, il sagit de relations de client
fournisseurs, dtermines par les rgles des contrats et
quasi-contrats, et fonctionnant selon les principes de la dlgation
tels quon les a prsents prcdemment.
Enfin, une objection pourrait tre faite ce principe de remonte
et redescente des informations et dcisions en cascade dans le rseau
des responsabilits de lO.T.: alors quon a voulu acclrer le
processus de dcision pour faire face aux alas survenant dans le
projet, et que pour cela on a dcid de crer une relation directe
entre les excutants et la direction de projet, on semble crer une
nouvelle pyramide gnratrice son tour dune lenteur de ractions. Il
nen est rien en ralit, car les ressources projets, avec le chef de
projet, font partie du groupe projet. Il ny a pas de notion de
hirarchie dans le fonctionnement du groupe projet, mais plutt une
notion de logique projet exprime par larborescence de lO.T.: pour
quun paquet de niveau n soit conforme ses spcifications, il faut
que les paquets constituants de niveau n + 1 en dessous rpondent de
leur ct aux fonctions et spcifications fixes. Le responsable du
paquet n, client des paquets n + 1 infrieur, sera donc inform
directement et immdiatement et pourra prendre les dcisions
ncessaires.
Mais tous ces responsables faisant partie du groupe projet, donc
participant aux runions internes projet, la circulation de niveau
en niveau dans lO.T. peut tre rduite la plupart du temps un
traitement simultan des informations et dcisions, en quipe.
Pouvoir du chef de projet; son profil
1. Quelle peut donc tre lautorit du chef de projet?
Un pralable important: quel que soit le sens donn au concept
dautorit, aucune rgle, aucun manuel ne pourra jamais donner aux
cadres la recette comment exercer cette autorit dans chaque cas;
seul peut exister un ensemble dides, de philosophie directrice.
Le chef de projet doit diriger des activits qui comprennent la
participation intensive et extensive dorganisation, de services,
qui ne sont pas sous son contrle direct. Dans cet environnement, le
fondement rel de linfluence dun homme est sa rputation
professionnelle; son exprience reconnue, seule, intervient et non
pas un document crit quelconque.
Lautorit du chef de projet est donc un mlange de facteurs jure
et facto; cest donc linfluence lgale et personnelle quil exerce
dans les problmes de planning, financier et technique, dans sa faon
de faire faire.
Lautorit du chef de projet doit se manifester delle-mme partir
de lexistence du projet; elle stend horizontalement et
verticalement et en diagonale et rayonne sur les organismes
extrieurs lentreprise.
Dans ces conditions, les relations traditionnelles jouent dans
un nouveau sens: un cadre de services fonctionnels ou mme
hirarchiques donne maintenant des conseils et fournit une aide
spcialise au chef de projet.
Le chef de projet na jamais dautorit unilatrale en ce qui
concerne son projet; il ngocie avec les cadres de lorganigramme.
Les relations quil noue forment un rseau dalliances qui ignorent la
chane hirarchique car elles se forment selon les besoins du projet,
mais dont il se sert.
Cette autorit du chef de projet sexprime par sa capacit de crer
ses rciprocits dans lenvironnement du projet, de crer et entretenir
des accords, de rsoudre des conflits entre personnes qui ne sont
ses subordonns, de prendre des dcisions autoritaires bases sur la
connaissance synthtique quil a de toutes les faces des
problmes.
2. Quelle est la place de la hirarchie ?
Dans la plupart des cas, les dcisions quauront prendre les
chelons hirarchiques ne seront pas plus que des approbations des
propositions du chef de projet. le rle jou par les cadres
hirarchiques risque alors de se dtriorer en des situations
prcaires.
Pourtant, le rle de lorganisation verticale conserve toute son
importance et sa ncessit; mais ce rle est de faciliter tout
lenvironnement du ou des projets. Cest aussi de son ct une
participation. Simplement, une nouvelle philosophie est ne de cette
prsence de lautorit projet: lappartenance une chane hirarchique ne
signifie pas que lon puisse diriger librement ceux qui se trouvent
en dessous. La notion de lobjectif est ici encore plus forte que
dans la direction dite par objectif car, si dans cette dernire
lobjectif peut souvent apparatre artificiel ou comme impos, pour le
projet, il est matrialis et clair. Il ne peut tre plus
motivant.
3. Quelle autorit lgale doit-on donner au chef de projet ?
Bien que son autorit soit plus personnelle que lgale, il est
ncessaire de la renforcer par des textes (lettre de mission par
exemple). Le rle du chef de projet, en ce qui concerne certaines
actions, peut-tre officialis sous forme dcrit:
- dfinition du projet et sa matrice;
- reconnaissance de son droit de passage horizontal dans la
pyramide;
- participation officielle et prvue toutes les dcisions qui
peuvent concerner le projet, quel quen soit le niveau
hirarchique;
- organisation du contrle par le chef de projet, de tout ce qui
concerne les budgets, les financements pour le projet;
- slection des contractants et participation aux
ngociations;
- droit de rsoudre certains conflits qui entravent la bonne
marche du projet;
- droit auto-dterminer son propre tat-major et en contrler la
composition;
- rle dorganisateur pour son systme dinformation
(dlais-cots-technique);
- maintenance des contacts et liaisons directes avec les
contractants et subcontractants;
- pouvoir de dcision en ce qui concerne le maintien et les
modifications des objectifs de son projet, selon les directives de
son client, matre douvrage;
- rle dorganisateur des relations du projet avec
lorganigramme;
- enfin, puisquon ne peut passer administrativement dun
organigramme contenant tous les individus de lentreprise, dfinition
de sa position hirarchique (bien que ce mot convienne mal). Cette
position sera la plus leve possible vis--vis de toute hirarchie;
mais elle dpendra de limportance du projet et de la diversit des
techniques.
Une formalisation de cette autorit projet doit tre faite dans
lentreprise.
4. Profil dun chef de projet
La vie du chef de projet et la nature de son travail se droulent
dans un univers quatre dimensions:
- la technique, dont les caractristiques principales sont
laspect pluridisciplinaire, la nouveaut donc linnovation, les
incertitudes et les alas;
- limportance des relations;
- la ncessit de gestion qui sajoute la matrise technique, et qui
doit tenir compte de linterdpendance des trois paramtres
cots-dlais-technique et des feed back dcisionnels en raison de la
nature systmique du projet;
- enfin lidentit mme du projet, son image originale et extrieure
la vie courante dans lentreprise, qui demande quon se dvoue pour
lui et non pour la pyramide.
Le projet est en dehors. Cest lexpression du besoin dun client
extrieur. De plus, on la sorti de lorganigramme de lentreprise; et
enfin non seulement le chef de projet, mais aussi, quoique un
moindre degr, les responsables projet dans les services, ont un rle
part. Il faut alors une certaine volont pour accepter cette
situation marginale par rapport la norme courante et quotidienne
des fonctions dans lentreprise.
Dun autre ct, il faut probablement plus de motivation quant
lobjectif (russir le projet) quil nen faut pour vivre au jour le
jour dans la pyramide hirarchique. Peut-tre mme faut-il une part
didal car dans un projet, mme petit, on va souvent vers
linconnu.
La matrise simultane de plusieurs disciplines trs diffrentes,
demande une comptence large et gnraliste; des connaissances de
spcialiste pointu ne peuvent que rarement suffire et risquent
parfois dorienter sur le dtail.
Le rflexe systme est trs important, dautant plus quinnovations
et checs alatoires ont toujours des consquences sur lensemble du
projet alors quils ne paraissent concerner que des parties parfois
mineures. A cet gard, tre trop sr de soi est souvent un frein
linnovation. Le chef de projet doit tre curieux et lcoute en
permanence; et aussi enthousiaste mais sans navet.
Cest enfin lesprit de synthse qui servira le plus.
Lquilibrage et linterdpendance des trois paramtres
cots-dlais-technique ajoutent encore aux difficults du chef de
projet. Cela ncessite de la mthode, un esprit dorganisation. Cela
requiert aussi une capacit de sentir le poids relatif des
jugements, des cots par exemple, car il ne faut pas senliser dans
les dtails, mais pas non plus laisser chapper le catalyseur de
catastrophe.
On peut se demander si la comptence en gestion nest pas la
premire qualit, avant mme la comptence technique; le fait que la
gestion se pose montre quil y a problme. Pratiquement, lquilibre
entre comptence gestion et comptence technique dpend et du projet,
et de la qualit de la dlgation et du bon esprit qui rgne dans
lentreprise: si le projet est mal vu, il faut tout faire. Dans tous
les cas, lincomptence ou le dgot pour lune des trois disciplines
est rdhibitoire.
En raison de sa place lextrieur de lentreprise dans son rle de
client, tout en en faisant partie, de labsence de moyens forts pour
obliger faire (sauf les contrats) et pour compenser son faible
pouvoir, qui nest fait que dinfluence (malgr mme toute lettre de
mission), le chef de projet doit user de qualits peu courantes et
quon nexige pas souvent en recrutement.
Son pouvoir ntant que dinfluence, il devra convaincre et pour
cela, il lui faut des talents de ngociateur; ce nest pas un gnral
qui impose ses vues par la force, mais un diplomate. Il lui faut
couter les propositions car les sous-traitants sont normalement
comptents et les problmes sont nouveaux. Personne ne sait vraiment
tout lavance, mais il lui faut savoir arrter les spculations et ne
pas se laisser aller au perfectionnisme, qui est de lintrt des
sous-traitants: caractre raliste mais pourtant cratif, prospectif
et en mme temps conservateur quant aux objectifs et au budget.
Le dosage entre initiative dans le cadre dune dlgation (contrat,
quasi-contrat), et respect strict des spcifications nest pas facile
car il faut la fois faire encore mieux et respecter lobjectif et le
besoin qui a conduit au projet.
Bien quon ait reconnu que le pouvoir du chef de projet est fait
surtout dinfluence, il lui faut pourtant de la fermet, de la tnacit
car les intrts et tendances de la multitude des sous-traitants et
excutants sont centrifuges. Il y a bien entendu toujours un recours
possible larbitrage (comit de pilotage, direction gnrale, voire
client) mais cette pratique trop frquente affaiblit le pouvoir du
chef de projet; sil peut se dbrouiller seul, cela lui donne plus de
force.
Enfin sur le plan caractriel, dans ses relations quotidiennes,
le chef de projet doit tre sociable, aimable, sympathique,
extraverti, etc., mais ne pas faire plaisir tout le monde
systmatiquement.
Cette numration de qualits est finalement impressionnante, et
lon peut se demander si de tels hommes existent. Il faut souvent se
contenter de quelques unes dentre elles, mais alors il les faut
bien choisir. Quoique laspect technique dans la plupart des projets
soit laspect fondamental (il faut arriver faire lobjet qui
fonctionne comme le demande le client), on peut penser que les
services excutants, sous-traitants sont comptents et quon na pas
leur tenir la main; ce quil faut cest les coordonner. Ce que ne
peuvent faire les responsables techniques de tous les paquets,
morceaux de projet, cest justement faire le lien, grer les
interfaces. Cest un problme de relation et cest surtout sur cette
capacit sociable quil faut insister pour un profil de chef de
projet.
PAGE 20
LE
PROJET
LES SERVICES
DE
LENTREPRISE
Service
de
lorganigramme
Paquet de
Excution
l O.T.
C
r
i
t
r
e
s
de
j
u
g
e
m
e
n
t
J
u
g
e
m
e
n
t
+
S
a
n
c
t
i
o
n
_
Champ des initiatives
Cadre des
+
+
+
Objectifs
Responsabilit
LA DELEGATION DONNEE AU CHEF DE PROJET OU AU
RESPONSABLE/PROJET
Russir le projet
Russir le paquet dO.T.
Contenir les performances
dans les spcifications
cot-dlai-technique
Faire faire par les fournisseurs
Projet - paquet de lO.T.
Objectifs
LA DELEGATION DONNEE AU CHEF DE SERVICE
Budget du service
Investissements, quipements
Emploi des plans de charge
Equilibre des plans de charge
Rpartition des tches
Programmation
Enrichissement et conservation du savoir-faire
Fonctionnement harmonieux du service
Formation
LA DELEGATION DONNEE A LEXECUTANT DUNE TACHE
Raliser une tche
Utiliser au mieux les moyens
Tenir le planning
Respecter les spcifications
cot-dlai-technique de la tche
Optimiser les conditions dexcution
Excutant
de la
tche
Chef
de
Service
Responsable
Projet
Allocation de la tche
Dlgation projet
Allocation de la tche
Dfinitions et recherche de consensus pour les spcifications
Contrle courant et volont
Information systmatique sur lavancement
Modifications mineures naffectant pas le service
(
(
Directives pour
modifications majeures
Modifications majeures
impliquant le service