plq structure matricielle

30
Daniel Leroy Maître de conférences à l’I.A.E. de Lille Directeur du DESS Gestion de Projets FICHE TECHNIQUE: LES PROBLEMES ORGANISATIONNELS LIES AUX STRUCTURES REALISANT DES PROJETS Principe: il est nécessaire de placer la conduite du projet sous une autorité unique et indépendante des hiérarchies qui le réalisent:la « structure matricielle » définit la relation entre le chef de projet qui prend le statut de client et les services exécutants qui doivent être considérés comme des fournisseurs. * Généralement, les objectifs des services de l’entreprise et ceux du projet sont concurrents et souvent contradictoires, d’où des cas graves de DYSFONCTIONNEMENTS...M 1.Abus de pouvoir d’un chef de service sur le projet Un premier cas de dysfonctionnement concerne les manipulations budgétaires faites aux dépens du projet par les responsables de service: parfois sur les directives du directeur général, ou bien même de sa propre initiative, un responsable dont le service exécute des paquets de tâches pour plusieurs projets décide d’utiliser le budget qui lui a été alloué pour un projet, pour les besoins urgents d’un autre projet, lui, en retard. S’il se trouve qu’un service, à un niveau assez global de l’organigramme hiérarchique, réalise plusieurs projets, ou complètement ou en grande partie, un arbitrage se crée ainsi tout naturellement, indépendamment des objectifs de chaque projet. Des manipulations encore plus gênantes peuvent être faites: en dépassement de dépenses sur les travaux d’un projet, et au large sur un autre, certains responsables de service trouvent intérêt, au sens de leur objectif propre, à imputer les factures du projet « dans la gêne » sur le budget du projet, plus riche. De tels transferts de codification, répondant aux besoins immédiats d’équilibre des budgets de service, surviennent malheureusement souvent, aux dépens des projets; toute crédibilité et toute possibilité de contrôle sont ainsi retirées au projet, il n’y a plus de gestion mais simplement de la comptabilité. 1

Upload: simo-qz

Post on 17-Sep-2015

227 views

Category:

Documents


0 download

DESCRIPTION

PLQ Structure Matricielle

TRANSCRIPT

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