Mòdul 2. Gestió de Projectes

Gesti deprojectes

Laura Bentez GarcaEugnia de Vilar FontJordi Folch Mola

PID_00165691

FUOC PID_00165691 Gesti de projectes

Cap part d'aquesta publicaci, incloent-hi el disseny general i la coberta, no pot ser copiada,reproduda, emmagatzemada o transmesa de cap manera ni per cap mitj, tant si s elctric comqumic, mecnic, ptic, de gravaci, de fotocpia o per altres mtodes, sense l'autoritzaciprvia per escrit dels titulars del copyright.


ndex

Introducci.................................................................................................. 5

1. El projecte i la gesti de projectes................................................ 71.1. Exemples de projectes ................................................................. 91.2. Projectes multimdia ................................................................... 10

1.2.1. Tipologia dels projectes multimdia ............................. 111.3. Tipologia de projectes ................................................................. 12

1.3.1. Segons la dimensi ........................................................ 121.3.2. Segons el client .............................................................. 12

1.4. El triangle de la gesti de projectes ............................................ 141.5. Factors d'xit d'un projecte ......................................................... 15

2. Habilitats per a gestionar projectes............................................. 172.1. Definici del projecte .................................................................. 172.2. Planificaci del treball ................................................................ 172.3. Administraci de contractes ....................................................... 182.4. Administraci de provedors ....................................................... 182.5. Administraci del pla de treball ................................................. 192.6. Administraci de situacions ........................................................ 202.7. Administraci de l'abast .............................................................. 202.8. Administraci de riscos ............................................................... 212.9. Administraci de la comunicaci ............................................... 222.10. Administraci de la documentaci ............................................. 232.11. Administraci de la qualitat ....................................................... 232.12. Administraci de les mtriques .................................................. 24

3. La planificaci.................................................................................... 253.1. Etapes d'un projecte web ............................................................ 25

4. Metodologia de planificaci d'un projecte.................................. 294.1. Definici dels recursos necessaris per a assolir els objectius ....... 304.2. Revisi de la definici del projecte ............................................. 314.3. Tasques i subtasques ................................................................... 314.4. Estimaci de temps dedicat a les activitats ................................. 324.5. Relacions i dependncies entre activitats ................................... 334.6. Aprovaci de la planificaci ....................................................... 344.7. La posada en marxa .................................................................... 34

5. Seguiment del projecte..................................................................... 355.1. El seguiment i control d'un projecte .......................................... 355.2. El pla de treball, una eina viva ................................................... 35


5.3. Activitats problemtiques, cam crtic ........................................ 365.4. Resultats i tasques d'un projecte ................................................. 37

6. El pressupost........................................................................................ 386.1. Qu s un pressupost .................................................................. 386.2. Necessitat del pressupost ............................................................ 396.3. Tipus de pressupostos ................................................................. 396.4. Factors que s'han de tenir en compte en un pressupost ............. 41

6.4.1. Models per a elaborar un pressupost ............................. 42

Bibliografia................................................................................................. 43

FUOC PID_00165691 5 Gesti de projectes

Introducci

La gesti d'un projecte s un dels factors principals que en determinaran l'xito el fracs. Per aix definirem qu s un projecte i de quins elements es com-pon.

Descriurem una metodologia genrica per a la direcci de projectes i veuremcom aplicar-la a projectes multimdia.


1. El projecte i la gesti de projectes

Dues bones definicions de projecte sn les aportades per Lewis i per Gido iClements:

"Un proyecto es un trabajo singular con unas fechas definidas de inicio y finalizacin,una especificacin clara del objetivo o alcance de la tarea, un presupuesto preestableci-do y, habitualmente, una organizacin temporal que se desmantela cuando termina elproyecto."

James P. Lewis (1995). Planificacin, programacin y control de proyectos. Barcelona: Edici-ones S.

"Un proyecto es un intento por lograr un objetivo especfico mediante un juego nicode tareas interrelacionadas y el uso efectivo de los recursos."

Jack Gido; James P. Clements (1999). Administracin exitosa de proyectos. InternationalThomson Editores.

Amb aquestes dues definicions, i algunes d'aportades per altres terics, comPerea, podem extreure les caracterstiques principals d'un projecte:

s singular: no es repeteix, s nic.

T uncomenamentiunfinal.

T uns objectiusclars.

T un joc (nic) de tasquesinterrelacionades.

Requereix un s efectiu dels recursos.

T un pressupost preestablert.

T una organitzacitemporal que acaba en finalitzar el projecte.

s dinmic, est en evoluci contnua.

s irreversible, ja que la presa de decisions marca l'evoluci del projecte i,la majoria de les vegades, aquestes decisions sn irreversibles; una vegadapreses ja no es pot tornar enrere.

T un component de risc, ateses les planificacions estimades amb qu esmou.


T un client: pot ser intern (de la mateixa empresa), o extern, per semprehi ha un client que encarrega el projecte.

Els factors essencials que componen un projecte sn els segents:

1)Ladurada(timing)delprojecte

Els projectes tenen una data de comenament i una data d'acabament o final.Els projectes interactius no solen tenir una durada excessiva (de dos a nou me-sos). Els projectes comencen quan el client autoritza i accepta la propostadeprojecte, en la qual presentem el pressupost i els recursos que seran necessaris.Un projecte s'acaba quan hem assolit les fites o objectius de la proposta. Elfactor temps s un dels punts crtics en el desenvolupament d'interactius; calcomplir els terminis (parcials o totals) d'acabament de les tasques o subtasquesprevistes.

Abans d'assolir l'objectiu o la data final, el projecte pot tenir dates intermdiesimportants (anomenades fites o dates clau) en qu s'han de concretar parts ocaracterstiques del producte que denominen lliurables. Cada lliurable o dataclau assolida amb xit i a temps ajuden a complir la temporalitzaci establertaper al projecte global i dins del pressupost assignat.

2)L'esforoelsrecursospersonalsimaterialsnecessarisperaferelpro-jecte

Els projectes desenvolupen o impliquen una srie de tasques relacionades en-tre si. Per a dur a terme aquestes tasques sn necessaris recursos personals ohumans (la gent que participar en l'elaboraci del projecte) i recursos mate-rials (eines maquinari, programari o altres elements fsics, com ara llocs detreball o material d'oficina).

3)Elsobjectiusperaaconseguirunproductenic(singular)

Un projecte es fa per a assolir uns objectius o obtenir uns resultats, per tambsn importants els objectius parcials o intermedis. El pblic a qu est destinatel producte o servei i els objectius que es pretenen aconseguir amb la materi-alitzaci d'aquest producte o servei han de guiar a tot l'equip durant el procsde creaci d'un interactiu. En un projecte volem assolir un objectiu en un ter-mini de temps i dins d'un pressupost previst i, sens dubte, limitat.

Els projectes que abordarem sempre seran nics (en equip, en client, en pro-ducte resultant, en temps, etc.), independentment de les nostres experinci-es professionals i laborals; per aix el producte fruit d'aquest projecte ser unproducte singular, i la singularitat marcar significativament el projecte.

Referncia bibliogrfica

JaimePereaBrand (1996).Direccin y gestin de proyectos(2a. ed.). Madrid: EdicionesDaz de Santos, SA.


1.1. Exemples de projectes

Per a entendre millor tot aix, veurem uns quants exemples del que s que sun projecte i del que no ho s.

Squesunprojecte

La construcci d'un edifici. L'elaboraci d'una campanya de mrqueting i promoci. El disseny i l'elaboraci de la collecci de tardor d'una marca de roba. La construcci d'un campus virtual. La producci d'un llargmetratge.

Fins i tot dins d'un mateix projecte hi pot haver subprojectes. En el cas de laconstrucci d'un edifici, per exemple, hi pot haver els subprojectes segents,fets cadascun per empreses i equips de projecte diferents:

Subprojecte de fonamentaci (fer els fonaments de l'edifici; t el seu propiinici i el seu propi final, els seus objectius i el seu equip de treball i tasquesprpies).

Subprojecte de construcci de l'habitatge (una vegada fets els fonaments,un altre equip de treball, amb el seu calendari, les seves tasques i els seusobjectius, construeix l'habitatge).

Subprojecte d'enjardinament (aquest projecte el pot desenvolupar una al-tra empresa, i tamb t les seves prpies dates d'inici i final, i un equip iuna planificaci totalment propis).

Subprojecte de decoraci (un equip es pot dedicar a dissenyar la decoracide l'interior de l'edifici).

Aquests subprojectes es poden entendre com a grups de tasques dins d'unaplanificaci global del projecte Construcci d'un edifici.

Vistos aquests exemples del que s que s un projecte, veurem alguns exem-ples d'activitats que no ho sn i que, per tant, no es poden gestionar amb lesmateixes pautes de gesti que un projecte.

Nosunprojecte

El manteniment d'un portal d'Internet (no t data d'acabament, no t unsobjectius finals que culminaran en un producte o servei concret, t unestasques ccliques, no canviants; dins del manteniment de vegades podensorgir projectes, com la incorporaci d'un servei nou al portal, per exem-ple, de compra electrnica, que s que es pot tractar com un projecte).

Vegeu tamb

En l'apartat "Metodologia deplanificaci d'un projecte" po-deu ampliar informaci sobreels subprojectes.


L'activitat comercial d'una botiga (tamb maneja diverses persones i t ob-jectius, per no t data d'acabament, ni ha d'acabar amb un producte con-cret. No s'ha de gestionar, per tant, com un projecte).

La feina de cada dia d'un programa de televisi (en aquest cas s projectetota la fase de disseny del programa, en el qual s que hi ha dates d'inicii final, i uns objectius molt concrets que culminaran en el disseny d'unproducte, que s el programa; una vegada s'ha acabat aquest projecte decreaci del programa, la gesti ha de canviar, perqu ja no ens trobemdavant d'un projecte).

1.2. Projectes multimdia

Vistes les caracterstiques principals dels projectes en general, analitzarem qus exactament un projecte multimdia i quines caracterstiques especials trespecte a altres tipus de projectes.

Com veurem, hi ha molts tipus de projectes multimdia i, per aquest motiu,les pautes de gesti no sn sempre les mateixes, ni el perfil professional delseu equip o del seu cap de projecte. Malgrat aix, hi ha unes caracterstiquesespecfiques dels projectes multimdia que s important analitzar.

Si ens basem en les definicions aportades anteriorment, un projectemultimdia s un treball singular fet dins del sector de la indstria mul-timdia que, com tot projecte, t un carcter nic, un inici i un final,uns objectius clars i un joc de tasques interrelacionades per a dur-lo aterme.

El resultatfinal d'un projecte multimdia s un producte (diguem-ne aplica-ci, sistema o ttol), les caracterstiques bsiques del qual sn la multimedialitati la interactivitat. Normalment, l'objectiubsic d'aquests projectes multim-dia s oferir continguts i serveis a usuaris concrets. Aix, per multimedialitatens referim al fet que el producte resultant del projecte maneja diversos mit-jans de carcter diferent (text, fotografia, illustraci, grafisme, udio, vdeoo animaci) i que l'aportaci de continguts i serveis es fa per la combinacide tots aquests mitjans. Per interactivitat ens referim a la capacitat que t elsistema que generem d'interactuar amb la persona que l'usar, amb l'usuari.L'usuari dna "ordres" o fa "requeriments" al sistema i aquest li respon (i alrevs). De fet, per aix parlem d'usuaris quan ens referim a projectes multim-dia, i no d'"espectadors", perqu usen el sistema, no solament el miren.

Una altra de les caracterstiques d'un projecte multimdia s que tota la "mat-ria primera" que maneja acaba transformant-se, en ltima instncia, en infor-macidigital. Aix implica que, bviament, per al maneig de tota aquesta


informaci es necessitar una infraestructura de maquinari i programari queens possibiliti transformar i manejar segons les nostres necessitats especfiquestota la informaci digital. Per aquest motiu, la majoria dels membres de l'equipd'un projecte multimdia necessiten conixer les noves tecnologies (des detreballar en ordinador fins a la manera com afecta l'organitzaci el fet de tre-ballar en una xarxa informtica) i fer-ne un bon s.

D'altra banda, el mercatmultimdia s una indstria multisectorial, en quintervenen tipus d'empreses molt diferents, com editors, empreses de ma-quinari i de programari, empreses de xarxes, el sector del disseny grfic odistribudors. Aix fa que el projecte multimdia necessiti professionals de sec-tors molt diferents i que, al seu torn, el cap de projecte hagi de tenir una visimolt clara de les caracterstiques i tendncies de la indstria en qu es mou.

1.2.1. Tipologia dels projectes multimdia

Una tipologia possible dels projectes multimdia, es pot fer a partir del suportque tindr el sistema o l'aplicaci multimdia objecte de desenvolupament enel projecte. A partir d'aix, podem definir les tipologies bsiques segents deprojectes multimdia:

Com veiem en el quadre anterior, el suport del sistema multimdia que hemde desenvolupar en un projecte condiciona totalment el tipus de projecte quefarem. Les caracterstiques d'aquests projectes sn tan diferents que marcaranmolt el tipus d'equip hum i material que necessitarem i, sobretot, el resultatfinal del projecte i la distribuci d'aquest projecte.


Fixem-nos que, encara que sn tipus de projectes diferents, tots tenen en comque manegen informaci multimdia digital i que sn sistemes interactius.A ms, tots els exemples compleixen els requeriments que permeten que elsqualifiquem com a projectes (tenen un inici i un final i uns objectius moltconcrets; alhora, tots sn projectes nics, irrepetibles, que donen resposta auna necessitat molt concreta d'un client).

1.3. Tipologia de projectes

Una vegada vist qu s un projecte i, en concret, qu s un projecte multim-dia, veurem, breument, els tipus de projectes que hi ha. Segons la dimensid'un projecte o del tipus de client, les caracterstiques d'aquest seran diferentsi, per tant, la gesti que n'haurem de fer tamb variar.

1.3.1. Segons la dimensi

Quan parlem de dimensid'unprojecte ens referim a la quantitat d'hores quees necessiten per a dur-lo a terme. No s'ha de confondre dimensi d'un projec-te amb dimensi d'una aplicaci. Quan ens referim a la dimensid'unaapli-caci parlem de la quantitat d'informaci que hi ha en aquesta i s'acostumaa comptabilitzar en pgines o en mitjanes.

A continuaci presentem una classificaci possible dels projectes segons ladimensi que tenen, feta per Mochal en el seu Ten Step Project ManagementProcess. Aquesta classificaci est bastant estandarditzada:

Tipus de projectes segons la dimensi

Dimensi Horesdeproducci

Projecte petit 1-250 hores

Projecte mitj 251-2.500 hores

Projecte gran Ms de 2.500 hores

1.3.2. Segons el client

Una altra classificaci possible dels projectes, es pot fer segons el client.

Dimensi d'una aplicaci

Per exemple, l'aplicaci t vint-i-vuit tipus de pgines dife-rents, dues-centes cinquantafotografies, vuit vdeos, sis ani-macions i divuit arxius sonors.

Referncia bibliogrfica

TomMochal (2000). Ten StepProject Management Process[document en lnia].


Projectesinterns

Per clientintern ens referim a un departament de la nostra prpia empresaque ens encarrega de fer un projecte.

Projecte intern

Per exemple, imaginem-nos que treballem en el Departament de Desenvolupament Mul-timdia d'una editorial (som el departament encarregat de fer les aplicacions multimdiaque ven l'editorial, que tamb edita llibres i revistes). El Departament de Mrqueting ensencarrega que desenvolupem un lloc web promocional de l'empresa editorial en qu tre-ballem. Aix s un projecte intern.

Caracterstiques dels projectes interns

Msflexibilitat Els projectes interns tenen variacions, especialmentquant a la flexibilitat de planificaci. Normalment la da-ta de lliurament no s tan rgida, ja que si entren projec-tes nous i urgents, que als directius de l'empresa els in-teressa prioritzar, deixem el projecte intern en stand by,en espera d'acabar el projecte extern urgent. Quan s'haacabat, podem reemprendre el projecte intern.

Msproximitatambelclient Els projectes interns tamb tenen la caracterstica deproximitat amb el client. Aix permet al cap de projec-te contrastar l'evoluci del projecte amb molta regulari-tat amb el client i que aquest validi les diferents etapes.A ms, com que treballa a la mateixa empresa que elclient, l'equip de desenvolupament del projecte t msclar el marc de comunicaci corporativa en qu es mouaquest client i els objectius que t.

Msflexibilitatambelpressupost Encara que en moltes grans empreses els departamentstenen les seves prpies partides pressupostries i actuencom a microempreses dins de l'empresa mare, si durantel desenvolupament del projecte hi ha imprevistos (unpressupost ms gran del que s'esperava en una subcon-tractaci, una necessitat imprevista de compra d'un pro-gramari concret, etc.), hi ha ms possibilitats que se si-gui ms flexible en el pressupost si el projecte s interni, tamb, s menys probable que s'apliquin sancions depressupost per demora en el lliurament.

Projectesexterns

En el sector multimdia, la majoria de projectes acostumen a ser externs, tretque es treballi en les condicions descrites en els projectes interns (en el Depar-tament de Multimdia d'una gran empresa). Quan el client s una empresa oun particular de fora de la nostra empresa, que t una necessitat especfica iens encarrega un projecte per a donar resposta a la seva necessitat, ens trobemdavant d'un projecteextern.

Els projectes externs no tenen les facilitats descrites en els interns (flexibilitaten el calendari i en el pressupost), per, en canvi, el marge de guany que po-dem aplicar al pressupost s ms gran.


1.4. El triangle de la gesti de projectes

La gesti de projectes comprn la planificaci, la coordinaci iel seguiment de les tasques. La persona que fa aquesta gesti sl'administradora, el director o capdeprojecte.

La coordinaci de les tasques en alguns projectes s tan crucial que, si no esduen a terme dins del calendari previst, es pot posar en risc el projecte com-plet. Els caps de projecte han de ser capaos de preveure els projectes de mane-ra global i planificar-los de manera coordinada. Una planificaci correcta per-metr reconixer els punts crtics, els colls d'ampolla i els espais d'inactivitat,de manera que el cap de projecte pugui dirigir l'equip envers la consecuciefica dels objectius.

El concepte bsic que ha de manejar tot cap de projecte s el que es refereix altriangledelagestideprojectes. Es tracta de tenir molt clar des d'un principiquin s l'abast del projecte, el temps que requereix i els recursos/pressupostnecessaris per a completar-lo.

Triangle de la gesti de projectes

El temps s, com el nom indica, el temps que es t per a lliurar el projecte. El cost repre-senta els diners o recursos que es tenen per a fer el projecte. El concepte d'abast (scope)engloba les caracterstiques i funcions especfiques del projecte (inclosa laqualitat).

Aquests sn els tres parmetres bsics amb qu de trampejar l'administradorde projectes i que, al final, determinaran en gran manera el grau d'xit o fracsdel projecte.

En tot projecte, gran o petit, cal identificar clarament quin s l'abast que t, s adir, quins sn els requeriments que s'han de satisfer per a aconseguir els objec-tius. Partint d'aquesta informaci podem determinar quants recursos (gent, ei-nes, pressupost) necessitem per a desenvolupar-lo. Per aix depn del tempsen qu es requereix completar el projecte.


Habitualment un dels vrtexs del triangle s fix i els altres dos tenen una in-fluncia inversa entre si. Si tenim disponibilitat de recursos, llavors podremreduir el temps. Si no hi ha pressi de temps llavors podrem disposar de menyspersonal i recursos per a completar-lo.

Si se'ns dna flexibilitat pel que fa a l'abast que s'ha de cobrir, llavors podremreduir temps o recursos per al projecte.

L'xit d'un projecte depn en gran manera de la flexibilitat de qu es disposien la gesti d'aquests tres factors. El client del projecte en pot restringir dos,per mai tots tres. Difcilment ser viable un projecte amb data lmit, recursoslimitats i un objectiu o abast no negociable i, en cas que el projecte es duguia terme, probablement el nivell de qualitat del producte acabat haur quedatcomproms.

Per a aconseguir executar correctament el projecte i, per tant, assolir elsobjectius establerts en el temps fixat i amb els recursos fixats, el cap deprojecte ha de saber combinar correctament l'abast, el cost i el tempsde qu disposa. Comenar un projecte amb un pla de treball irreal s lamillor frmula per a fracassar en la gesti d'un projecte.

1.5. Factors d'xit d'un projecte

Els factors que cal controlar en un projecte i que, ben gestionats, poden ser laclau de l'xit d'un projecte sn:

Assolirelsobjectiusfixats.Hem de marcar objectius per a cada etapa del projecte i controlar queaquests objectius es van assolint. Si complim els objectius de les diversesetapes, tenim ms possibilitats que, una vegada acabat el projecte, com-plim els objectius generals.

Situant-nos en un exemple de projecte multimdia, imaginem-nos que un dels objectiusque ens hem marcat en l'etapa de disseny d'interfcie s que l'aspecte visual de l'aplicacies faci segons la imatge corporativa de l'empresa client. Si no aconseguim aquest objectiu,per ms que els objectius de les etapes segents s que els assolim (en la part de progra-maci o continguts textuals, per exemple), no haurem assolit els objectius generals, demanera que el client no estar content. El projecte haur fracassat noms perqu en unaetapa no s'han complert els objectius.

Nosuperarelscostos.Els costos s la quantitat que s'ha de pagar pel projecte que s'ha convingutamb el client. Sovint, si el lliurament del projecte es retarda, hi pot haversancions en l'import que queda al client per pagar. Un altre factor quepot fer superar els costos pactats s pagar ms els membres de l'equip delque s'ha estimat en el pressupost, o comprar maquinari o programari queno s'havia previst de comprar. Si el projecte inclou una subcontractaci,


tamb s important tenir el pressupost de les tasques subcontractades quanfem el pressupost general.

Complirelcalendariprogramat.Durant l'elaboraci d'un projecte s molt important seguir el calendari pla-nificat al comenament. Com veurem ms endavant, en la part dedicadaa la planificaci del projecte, en segons quines tasques s encara ms im-portant no retardar-nos, perqu significaran un retard en el lliurament fi-nal del projecte i, per tant, un fracs en la planificaci. Hem de tenir encompte que el retard en una tasca determinada (per exemple, l'elaboracidels grfics), pot retardar totes la tasques que van a continuaci (no po-dem integrar fins que no tinguem acabats els grfics; no podem fer provesfins que no hgim integrat; etc.). El cap de projecte, per tant, ha de fer unseguiment rigors del calendari.

Tenirelclientsatisfet.Aquest objectiu s fonamental. Si el client no est content, vol dir que nohem donat resposta a les seves necessitats i, per tant, el projecte haur fra-cassat. Per a evitar que el client mostri insatisfacci davant del projecte enuna fase avanada, s important que vegi mostres de la manera com avan-cen les diferents tasques, com veurem ms endavant. Hem de tenir unacomunicaci proactiva amb el client, "obligar-lo" a comunicar-se amb nos-altres i a fer un seguiment, amb l'objectiu de validar els diferents avenosdel projecte.


2. Habilitats per a gestionar projectes

A continuaci veurem les dotze habilitats bsiques perqu la gesti d'un pro-jecte culmini en l'elaboraci reeixida d'aquest projecte. Hi ha altres habilitatsnecessries en la gesti d'un projecte com el lideratge, l'escolta i una bonaretroalimentaci.

Alguns dels aspectes de l'administraci de projectes, com el fet de definir elprojecte i administrar situacions, es poden aplicar a tots els projectes. D'altres,com el maneig de la documentaci i les mtriques, cobren ms importnciaen projectes de gran envergadura.

2.1. Definici del projecte

Abans de comenar el projecte, s indispensable que s'hagi ents el treball ques'ha de fer i que els responsables, tant els de l'execuci del projecte com elsque en rebran els resultats, tinguin una visi clara dels resultats esperats, tanten durada com en costos, crregues de treball i beneficis.

Petit o gran, la definici de l'abast del projecte s eina vital perqu el cap deprojecte o els comits respectius, si n'hi ha, puguin prendre decisions en lesetapes administratives que s'esmentaran ms endavant. Les decisions presesen aquesta etapa del projecte marcaran l'xit o fracs del projecte.

Com ms gran s el projecte ms gran s la importncia de deixar estipuladaexplcitament aquesta informaci. El resultat d'aquesta activitat ha de ser undocument titulat Definici del projecte i ha d'incloure la informaci esmentadaen el primer pargraf.

Al final d'aquesta etapa, s'ha de tenir un document amb l'abast i expectativadel projecte, com es mesurar, qui ho far i quant costar. Aquest documentl'han d'haver aprovat tots els involucrats, perqu mirar de buscar consens sobreaquests temes en un projecte que ja ha arrencat s extremament difcil.

2.2. Planificaci del treball

En l'etapa de planificaci es determina com es far el treball. Aix implicaelaborar llavors un pla per al treball. Es poden usar diferents mitjans per a laplanificaci, des d'un full de paper per a un projecte petit, fins a solucionssistematitzades com el Microsoft Project per a projectes ms complexos.

Si no es t una plantilla per al pla de treball, es recomana seguir la metodolo-gia d'anlisi estructurada descendent. Seguint aquesta metodologia, el projec-te es divideix en tasques que, al seu torn, sn desglossades en subtasques ms

Vegeu tamb

Trobareu ms informaci so-bre el lideratge, l'escolta i laretroalimentaci en el mdul"El costat hum de la gesti deprojectes".


detallades. Aquesta seqncia es repeteix fins que s'obt prou nivell de detallperqu el projecte sigui comprs totalment. Es recomana anar amb compteamb el nivell de detall, perqu partir el projecte en components exagerada-ment petits pot ocasionar costos alts d'ineficincia, tant d'elaboraci com demanteniment.

Una recomanaci s usar una fracci de la durada total del projecte.

Per exemple, si el projecte dura un any, la tasca ms petita ha de ser en setmanes. Si elprojecte dura mesos, la tasca ms petita ha de ser en dies, i si el projecte dura setmanes,la tasca ms petita ha de ser de quatre hores. No t sentit incorporar activitats de menysdurada de les estipulades aqu, llevat que siguin fites dins del projecte.

Una vegada es t la llista d'activitats, el pas segent s estructurar la dependn-cia d'aquestes activitats. No es poden desenvolupar totes alhora. Quan s'haculminat aquest procs de dependncies, es passa a assignar els recursos a ca-dascuna de les activitats. Aquests recursos inclouen personal, diners i elementsrequerits.

Es recomana tenir en compte sols sis hores hbils per dia feiner i deixar eltemps restant per a ajustos en la planificaci del projecte. Si el clcul de tempsmanca de marge sol ser necessari ajustar cronogrames i dates, cosa que generauna sensaci de descoordinaci que sol desmotivar l'equip de treball.

2.3. Administraci de contractes

Hi ha dos temes fonamentals en l'administraci d'un contracte:

el lliurament dels resultats (lliurables) i el compliment de les dates per a aquests lliuraments.

Per a tots dos s'estableixen criteris i requeriments que permeten controlar-neel compliment.

Amb freqncia es descuida que el contracte s un document legal, regit pelcodi de comer de cada pas. De la mateixa manera, es converteix en necessitatsaber si hi ha penalitzacions per incompliment de calendari de lliuramentsparcial o total del projecte i, si es defineixen lliurables, saber-ne exactament ladefinici i el suport en qu els facilitaran.

2.4. Administraci de provedors

En el transcurs del projecte, la relaci amb els provedors pot arribar a variarmolt. Aquesta variaci est estretament lligada a l'aven del projecte. Habitu-alment al comenament del projecte no hi sol haver cap contratemps: el clientacaba de contractar qui ha considerat la millor opci en un procs de seleccii el provedor acaba d'adquirir un client nou.


Una vegada iniciat el projecte es poden detectar diferncies de criteris id'abastos per als lliurables. En l'administraci de contractes i en el procs decontractaci no sempre queda totalment definida la relaci amb el provedori les seves obligacions.

s necessari tenir clar, per exemple, qui sufraga els costos de viatges i allotjament, comes relacionen dins del projecte, quins sn els documents per a exigir el pagament i cadaquan es presenten aquests pagaments.

Igualment s imperant establir com es manejaran els incompliments, normalsfins a cert punt, entre el que s'ha programat al comenament i el que realmentha lliurat el provedor. Hi ha dos tipus d'incompliments:

el d'especificacions o funci requerida, i el de temps.

Un projecte, depenent de l'envergadura, pot arribar a tenir diversos provedorsinteractuant. S'han de definir tamb els mecanismes d'assignaci de responsa-bilitats de tal manera que no es pugui rebotar d'un provedor a l'altre la solucia un problema.

2.5. Administraci del pla de treball

Fins aqu ja s'ha definit el projecte i s'ha planejat el treball. Els lliurables delprojecte fins ara sn:

la definici del projecte, el pla de treball, el contracte i el manual d'administraci del projecte.

El pla de treball s noms un lliurable. Descriu el que cal fer, l'ordre del treball,l'esfor que es requereix i qui est assignat a quina tasca, per noms represental'estimaci ms bona de la manera com s'ha de completar el treball que quedaper fer en un moment concret d'un projecte.

Com ms complex s el projecte, ms canvis es presenten en el pla de treballamb el pas del temps. El gestor de projecte ha de revisar els plans de treballde manera permanent (setmanalment, com a mnim) i determinar-ne l'estatactual.

Es fa indispensable l's de la gesti proactiva, de tal manera que s'identifiquinles activitats que s'han de complir a curt termini, i d'acord amb aix i l'impacteque t dins dels cronogrames i els objectius del projecte, fer els ajustos neces-saris perqu els objectius es compleixin. Qualsevol canvi en els cronogrames,els criteris d'acceptaci i els objectius establerts l'ha de resoldre un comit decanvis. Ha de quedar clar per a tots els qui estan involucrats en el projecteque aquests canvis afecten l'abast del contracte, de manera que no es poden


assumir unilateralment. Les peticions de canvi s'han d'analitzar, s'ha d'avaluarl'impacte i el risc que comporta acceptar-los i prendre les decisions adequadessobre aix.

Gesti proactiva

Per exemple, pot ser necessari assignar ms recursos o ajornar la data d'acabament delprojecte o desestimar alguna de les tasques previstes que es consideri de menys importn-cia que el canvi demanat.

2.6. Administraci de situacions

Una situaci es presenta quan un problema pot arribar a impedir o impedeixel progrs del projecte i no el pot resoldre el gerent del projecte i l'equip delprojecte sense ajuda externa.

Quan es presenta aquest tipus de situacions, no queda ms alternativa que re-soldre el problema. Es recomana aplicar-hi tcniques de maneig de situacions,la qual t dos components.

El primer s tenir un procs que permeti trobar aquestes situacions i treu-re-les a la llum, determinar-ne l'impacte en el projecte, avaluar les alterna-tives i aconseguir les persones que permetin prendre la millor decisi ate-ses les circumstncies. Aquest procs ha de formar part del procs generald'administraci del projecte i ha d'estar definit abans de comenar el projecte.

El segon component s aplicar tcniques de soluci de problemes per a resoldreaquestes situacions. Aix inclou entendre eines com els diagrames d'espinade peix, els diagrames de Pareto i l'anlisi de causa i efecte. El fet de conixeraquestes eines permet que l'equip entengui la ra del problema, determiniaccions disponibles i quina s l'alternativa ms bona de prendre.

s important tenir en compte que tenir un procs per a resoldre situacionsno s el mateix que tenir l'habilitat de resoldre-les reeixidament. En algunscasos hi ha alternatives millors i el treball del grup de projecte s trobar-les iaplicar-les. En altres casos no hi ha una soluci bona per a aquestes situacions.En aquest cas cal prendre la decisi que faci menys mal, o l'alternativa "menysdolenta".

2.7. Administraci de l'abast

L'abast d'un projecte descriu els lmits d'aquest projecte i el que el projectelliurar, quina informaci es necessita i quines parts de l'organitzaci en que-daran afectades.

L'administraci de canvis en l'abast comena amb la definici de qu s uncanvi d'abast. Si el gestor del projecte no ha definit b l'abast inicial, ser tre-mendament difcil administrar aquest abast durant el projecte. El propsit del'administraci de canvis en l'abast s protegir la viabilitat de la definici del


projecte que ja s'ha definit i aprovat. Quan es va definir el projecte, tamb esvan definir i estipular les expectatives de resultats. Durant la vida del projec-te s normal que es requereixin tems diferents o addicionals als inclosos enla definici original del projecte. Ha de quedar clar, per a totes les parts, quecomplir aquests requeriments nous amb els mateixos recursos de la definicianterior, s prcticament impossible. En general els canvis comporten costosms grans i retarden l'obtenci dels resultats, dos temes que impacten direc-tament en les possibilitats d'xit o fracs del projecte.

L'aprovaci dels canvis en l'abast l'han de fer conjuntament els clients i elsprovedors, ja que s l'nica manera que s'assignin els recursos addicionalsnecessaris i s'ajustin les expectatives dels qui hi estan involucrats. s habitualque en afegir un canvi que introdueix una funcionalitat no prevista en l'abastoriginal es descarti alguna de les funcionalitats secundries del projecte si noes poden assignar ms recursos o no es pot modificar el temps d'acabament.

Un dels problemes principals que apareixen en gestionar l'abast del projectes que s'accepten canvis petits que a simple vista no afecten gaire el projectei s'infravalora l'efecte conjunt de molts canvis petits.

2.8. Administraci de riscos

El risc s una situaci futura que hi ha fora del control del projecte ique pot tenir un impacte negatiu sobre el resultat del projecte si s'arribaa produir.

Els administradors reactius s'esperen a resoldre la situaci quan succeeix. Elsadministradors proactius miren d'identificar i resoldre problemes potencialsabans que ocorrin.

Els projectes petits, per la durada curta que tenen, no donen gaire cabuda al'aparici de problemes. En canvi, els projectes grans sn propensos a tenir-ne.En la gesti del projecte s'han d'identificar tots els riscos possibles, determi-nar-ne la probabilitat i analitzar l'impacte en el projecte, si ocorren.

Una vegada identificat el risc que es vol administrar, hi ha cinc alternativesd'acci possibles:

Noferres. No es fa res si es determina que l'efecte sobre el projecte s in-significant davant de l'ocurrncia del risc, o no es pot fer res per a atendre'l.

Ferunseguiment. Es fa un seguiment del risc de manera que es puguideterminar la probabilitat que es doni o no en el transcurs del temps. Si


aparentment augmenta la probabilitat que ocorri a mesura que passa eltemps, s'ha d'atendre en aquell moment.

Evitarelrisc. S'ha d'eliminar la condici que pot causar el problema.

Per exemple, els riscos que presenta un provedor, es poden evitar contractant-ne un altre.

Traslladarelrisc. En alguns casos s factible que l'administraci del riscsigui assignada a una altra entitat o tercera part que no sigui l'administracidel projecte.

Mitigarelrisc. En la majoria dels casos aquesta s la mesura que s'ha deprendre. Si s'ha detectat un risc, es pot elaborar un pla per a garantir queel risc no ocorri o, si ho fa, perqu l'impacte que t sigui insignificant.

Com amb l'administraci de l'abast, no hi ha res de dolent que hi hagi riscosen un projecte. No es pretn que un projecte no tingui riscos; el que importas la resposta que s'hi dna. Si s'ignoren els riscos, es convertiran en situacionsi llavors hi haur menys opcions per a solucionar-los.

2.9. Administraci de la comunicaci

Aquesta activitat s una les activitats crtiques en un projecte i s fonamentalen l'administraci dels objectius i els receptors dels beneficis d'aquest projecte.

Hi ha dos nivells de comunicaci en un projecte. Tots els projectes han decomunicar l'estat del projecte. Addicionalment, si el projecte s complex o msgran, es necessita un nivell ms sofisticat de comunicaci definit en un pladecomunicacions.

Les reunions d'estat i l'informe d'estat del projecte s on s'estipula l'aven delprojecte, els problemes, les activitats acomplertes, la revisi del flux de caixai la proximitat dels lliurables. En general, es defineix un informe amb formatestndard en qu es resumeix l'aven i s'alerta sobre problemes possibles.

Quan el projecte s d'una gran envergadura, es requereix un pla de comuni-cacions que no solament informi sobre el projecte sin que ajudi en la imple-mentaci del canvi.

La comunicaci s'ha de gestionar de manera proactiva, ha d'estar planificadai executada per a garantir la bona comunicaci entre els actors principals delprojecte: el client i els provedors.


2.10. Administraci de la documentaci

L'administraci de la documentaci s una d'aquelles activitats que els caps deprojectes donen per fetes, fins que es veuen inundats de paper. Per a projectespetits no hi ha necessitat d'establir tot un sistema administratiu, per en lamesura que l'abast del projecte augmenta, es fa necessari tenir-lo.

Encara que s una de les tasques que poden assistir tecnologies com un repo-sitori documental, aquestes eines poden ser difcils d'administrar i incorporenms problemes al projecte.

S'ha de decidir com s'han de codificar els documents, quins tipus de docu-ments es volen emmagatzemar, per quant temps, en quin format i com s'hande classificar. Independentment de si es decideix organitzar la documentacisegons la font de la informaci o per l'objecte d'aquesta, el realment importants que es defineixi quin tipus de classificaci s'utilitzar.

Un exemple de definici de classificaci s, d'una banda, la informaciadministrativa,informaci general del projecte, s a dir, contractes, plisses i report de compliments;de l'altra, la informacirelativaacadaxiti, finalment, les actes consecutives de lesreunions dels diferents estaments de decisi.

Si els projectes tenen prou envergadura, s recomanable usar un lloc web dinsde la intranet de l'empresa per a emmagatzemar aquesta informaci i que siguipublicada i accessible tothora.

2.11. Administraci de la qualitat

La qualitat d'un projecte es mesura per si sn gaire a prop de complir-se lesexpectatives i els lliurables per al client; per tant, l'objectiu central de l'equipdel projecte s mirar de complir i fins i tot superar els requeriments del client.Hi ha una tendncia a equiparar la qualitat amb el millor material, el millorequip i zero defectes. Tanmateix, en la majoria dels casos, el client no esperai no pot costejar una soluci perfecta.

Un dels propsits del control de qualitat s detectar errors tan aviat com espugui en la vida del projecte i aix disminuir-ne l'impacte tant econmic comde temps d'elaboraci.

Per a administrar la qualitat cal obtenir una definici correcta de l'expectativadel client. Aquesta definici es fa amb la quantificaci d'alguna cosa que ori-ginalment es percep com a subjectiva. S'ha de definir la qualitat segons unnombre de caracterstiques que es puguin definir de manera tangible i desprsveure com es mesura cadascuna d'aquestes caracterstiques.


El mesurament de la qualitat ha de ser un procs continu. Una de les tcniqueshabituals per a fer aquest procs de manera efectiva s l's dels denominatscercles de qualitat.

Un cercle de qualitat s un grup de treball, conformat per persones quefan tasques similars i que, amb una periodicitat regular, es reuneixenper a identificar les causes dels problemes dels seus treballs a fi de pro-posar-hi solucions.

Una de les tcniques ms emprades en el control de qualitat s l's de llistesde comprovaci de passos o funcionalitats, en el cas del desenvolupamentde programari, per a garantir que el producte es lliura complet i funcionantcorrectament.

2.12. Administraci de les mtriques

L'habilitat de maneig de projectes ms sofisticada s obtenir les mtriques d'unprojecte, i es pot convertir en la ms difcil. Les mtriques sn, en general,difcils de definir i recopilar, raons per les quals s'ignoren o es manegen demanera inadequada.

S'han de definir mtriques bsiques que permetin mesurar l'esfor, el cost i eltemps d'acabament. Tamb s'hi han d'incloure mtriques que determinin elgrau de satisfacci dels requeriments del client i del compliment de les sevesexpectatives. Depenent dels resultats cal prendre els correctius pertinents.

Per a fixar les mtriques per al projecte, se suggereix identificar els criterisd'xit en termes de lliurables i execuci, determinar com s'ha de mesurar tantl'xit final com l'aven, seleccionar un nombre apropiat de mtriques i recollirla informaci. s d'una importncia vital collocar parmetres de comparacimitjanant la definici de metes o fites, ja que les mtriques per si soles nodiuen gaire.

En general, aquest procs s de poca importncia per a projectes petits ja queno hi ha temps de recopilar els valors i menys d'analitzar-los i fer-hi correctius.


3. La planificaci

Per a gestionar un projecte de manera efica i eficient necessitem planificar-lo correctament. La planificaci detalla els objectius o resultats del projecte,la manera d'aconseguir-ho i els recursos humans i materials que necessitemper a aix. Tota aquesta informaci la plasmem en el pladeproducci, undocument bsic per al desenvolupament i execuci del projecte. Aquest docu-ment s fonamental per a donar suport al cap del projecte i el seu equip durantl'execuci del projecte.

Una vegada aprovada la proposta, s'ha de detallar molt ms el pla previ i s'hihan d'incloure les tasques assignades als diversos membres que componenl'equip de treball i la identificaci de fites. El document de la planificaci (plade producci) ha de ser a l'abast de qualsevol persona implicada en el projectei no solament del cap, de manera que si es produeix alguna modificaci, actu-alitzaci o canvi puguin prendre les mesures pertinents i tots els componentsde l'equip n'estiguin assabentats.

Abans d'entrar a parlar prpiament de la planificaci d'un projecte, s moltimportant tenir clares les etapes principals de la producci. Si un cap de pro-jecte no t clares aquestes etapes i les activitats principals que s'hi fan, difcil-ment podr fer un pla de treball efica.

3.1. Etapes d'un projecte web

En la producci d'una aplicaci multimdia per al Web intervenen moltes ac-tivitats que s'han de fer de manera cronolgicament successiva, ja que n'hiha moltes que no poden comenar fins que d'altres no estan acabades. Abansd'entrar en la concreci de totes les activitats, s necessari tenir una idea ge-neral de les etapes per qu es passa en la producci del projecte. Bsicament,aquestes etapes sn els segents:

Vegeu tamb

En el mdul "Mercat i produc-tes multimdia" hem vist comes dissenya un producte mul-timdia: s'ha de crear un br-fing i en la definici i el pressu-post s'ha de definir l'abast delprojecte.


1)Definicideprojecte

s l'etapa en qu es concreta en qu consisteix el projecte. El document resul-tant s el de definici de projecte. Normalment es considera que aquesta fases prvia al projecte prpiament dit.

Normalment, aquesta fase s'acaba amb la firma, de les dues parts, del contracte.

2)Pladetreball

Una vegada concretada la definici del projecte, es comena a treballar pr-piament en el projecte. Abans de res, s important planificar tot el desenvo-lupament. Per aquest motiu hi ha una etapa intermdia que s'ha de tenir encompte, entre la definici del projecte i el comenament de la producci, ques la de pladetreball.

3)Disseny

Una vegada planificat el projecte, sobre les lnies generals que s'han pactat enla definici del projecte es comena a dissenyar exactament com ser. Quanens referim a disseny, no s'ha de cometre l'error de pensar noms en dissenygrfic. Dissenyar una aplicaci multimdia o un lloc web s concretar tot elque es far respecte als continguts, el nivell formal (grfic) i el nivell tcnic.Per aquest motiu, en aquesta etapa es fan tres anlisis diferents:

Anlisidecontinguts: es decideix tota l'estructura de continguts, serveisi funcionalitats.


Anlisiformal: es concreta la interfcie grfica.

Anlisi tcnica: es decideix la soluci tcnica que s'ha d'adoptar per alprojecte i l'estructura orgnica de l'aplicaci en l'mbit de programaci.

Durant aquesta etapa s'elaboren els diferents guions que s'utilitzaran en l'etapasegent, la de desenvolupament.

4)Desenvolupament

A partir de tot el que s'ha decidit en l'etapa de disseny, en aquesta etapa dedesenvolupament es concreta, es fa realitat. S'elaboren tots els grfics, els altreselements multimdia, es construeixen les pgines HTML, les bases de dades,s'escriu tota la programaci, etc.

5)Verificaci

Una vegada finalitzada l'etapa de desenvolupament, tenim el projecte acabat,per en una versi provisional. Per a validar-lo s'ha de verificar, provar querealment funciona. La verificaci s de diferents maneres:

Verificacitcnica: es comprova que l'aplicaci o el web funciona en totsels sistemes operatius o programaris o configuracions per als quals s'ha fet.

Per exemple, que funcioni en els sistemes operatius Windows, MacOS o Linux, que fun-cioni en els navegadors Microsoft Internet Explorer, Mozilla o Safari, que es vegi b endiferents resolucions de monitor, etc.

Verificacidefuncionalitat: es mira que l'aplicaci funcioni b: que totsels enllaos siguin correctes, que cada objecte tingui assignat el compor-tament que ha de tenir, que els elements multimdia siguin on han deser, etc.

Verificaciambusuaris: en projectes grans s important provar l'aplicaciamb una mostra real d'usuaris amb un perfil similar als usuaris en qui hemcentrat el disseny. Aquest tipus de verificacions les han de fer professionalsamb perfils relacionats amb la interacci persona-ordinador o el dissenycentrat en l'usuari.

Totes aquestes verificacions no tindrien sentit si, posteriorment, no es canvi-aven els aspectes que s'ha vist que no funcionen correctament.

D'altra banda, malgrat que la verificaci es considera com una etapa posteri-or al desenvolupament, s'ha d'entendre que al llarg del desenvolupament lesproves sn una acci que cal aplicar sistemticament. Quan un dissenyadorconstrueix una pgina HTML i fa el preview, prova, verifica de fet, aquesta p-


gina. Una altra manera de verificar el projecte, al llarg del desenvolupament,s ensenyar el que es fa als companys de l'equip de treball, perqu valorin sis'entn, si funciona b, etc.

6)Explotaci/implementaci

Una vegada acabada l'etapa de verificaci i fets tots els canvis oportuns, esdna per acabada la producci. En aquest punt entra l'etapa d'explotaci oimplementaci.

Exemples d'explotaci

En el cas d'un CD-ROM, entrem en tota la part d'embalatge, estampaci i distribuci. Enel cas d'un web, el penjarem i en farem un seguiment del funcionament i les visites.

Parlem d'implementaci quan ens referim a projectes amb un component altd'enginyeria informtica i en qu el projecte fet s'introduir en un sistema queja funciona.

Exemple d'implementaci

Si el projecte consistia en una aplicaci per a una intranet, una vegada fet, l'implementema la intranet.


4. Metodologia de planificaci d'un projecte

No hi ha una metodologia nica per a planificar un projecte. Cada cap deprojecte t els seus propis trucs a l'hora de fer el pla de treball. Malgrat aix,s bo utilitzar una proposta metodolgica per a construir el pla de treball, apartir de les tcniques que s'acostumen a utilitzar ms.

S'ha de tenir en compte que en els projectes petits es pot treballar amb unaplanificaci mnima, per en els projectes mitjans i grans s totalment impres-cindible fer, abans de comenar a desenvolupar el projecte, una planificaciexhaustiva.

Una vegada presa la decisi de posar en marxa el projecte i obtingudal'autoritzaci formal del client, els passos que s'han de seguir sn:

1) Dissenyar un pla de treball.2) Distribuir el treball entre els recursos disponibles.3) Presentar el calendari i la planificaci per a aprovar-los formalment.4) Comenar a executar o desenvolupar el pla de treball.

Les activitats bsiques implicades en la planificaci d'un projecte sn lessegents:

Identificar les tasques o subtasques i les dependncies que tenen.

Representar les tasques i dependncies amb un diagrama per a determinarla seqncia de tasques ms efica.

Estimar el grau d'esfor que es requereix en hores, dies o setmanes segonsla dimensi del projecte i la durada de cada tasca i subtasca.

Identificar els recursos i la disponibilitat (temps, com i quan).

Especificar les fites o objectius parcials.

Elaborar una llista dels "lliurables", molts dels quals coincidiran amb lesfites.

Presentar la planificaci obtinguda per a aprovar-la formalment.

Gesti de projectes

Algunes vegades es planteja si les hores emprades pel cap de projecte s'han d'incloure enla planificaci. La recomanaci s que les hores de gesti d'un projecte s'han d'incloureen la planificaci, perqu aquestes hores s'estenen des de l'inici fins al final del projecte ies tracta d'un recurs valorable que ha de formar part del pressupost global amb la forma


de sou de cap de projecte. Tanmateix, no sempre s recomanable que totes les tasquesdel cap de projecte es plasmin explcitament en la planificaci, ja que sn d'ndole moltdiversa i difcils de quantificar. Se sol calcular que el cap de projecte hi ha de dedicaraproximadament el 20% de la durada total del projecte; per aix s habitual assignar-liuna tasca genrica de gesti de projectes.

Les eines principals de planificaci de les tasques i subtasques sn:

L'estructuradedescomposicideltreball (EDT), que s una estructuraexhaustiva, jerrquica i descendent formada pels lliurables que s'han defer en un projecte. L'EDT s una eina molt comuna i crtica en la gestide projectes.

El diagramadeGantt mostra el temps de dedicaci previst per a diferentstasques o activitats al llarg del temps total del projecte.

El grficdePERT (Program evaluation and review technique) s un mtodeper a analitzar les tasques involucrades en un projecte concret, el tempsnecessari per a completar cada tasca i les dependncies entre aquestes tas-ques, i per a identificar el temps mnim necessari per a completar el pro-jecte total.

4.1. Definici dels recursos necessaris per a assolir els objectius

Abans de comenar un projecte s necessari esbrinar amb exactitud quins snels objectius que s'han d'aconseguir. En definir un projecte, Hallows suggereixunes quantes preguntes bsiques:

Estandefinitsels"lliurables"delprojecte? Els lliurables sn els resultats,les fites, els productes parcials o totals d'un projecte. Sn la prova quel'equip de projecte treballa. Els equips mal gestionats es concentren msen la producci d'un lliurable parcial que en el mateix lliurable final; lasoluci consisteix a definir amb precisi el que cal fer i mantenir-se en lamateixa lnia per a assolir els objectius desitjats.

Estdefinitl'mbitdelprojecte? Hem de fer un esfor per determinar elgrau d'esfor necessari per a cobrir tots els aspectes d'un projecte i, sovint,hem d'usar totes les eines que tinguem a l'abast (representaci grfica).

Estdeterminadalamaneraenquelslliurablesseranrevisatsiapro-vats? Ens hem d'assegurar des del comenament del projecte que tothomest d'acord amb els objectius que s'han d'aconseguir i, per tant, amb elsmitjans utilitzats per a revisar i aprovar cada tasca de l'equip i fins i totdel cap de projecte.


4.2. Revisi de la definici del projecte

El primer pas fonamental quan comencem a desenvolupar el pla de treballd'un projecte s revisar la definici de projecte que hem pactat amb el client.s important fer aquesta revisi per a assegurar-nos que s'entn exactament enqu consisteix el projecte, qu s el que s'ha de produir. Igualment, la definicide projecte ens donar els parmetres de calendari sobre els quals ens hem demoure.

En els projectes grans s molt til que la definici del projecte contingui unadescripci molt completa del projecte. De vegades, abans d'entrar prpiamenten la fase de planificaci o disseny del pla de treball, s'acostuma a fer unaprimera planificaci aproximada, que el client ha de validar juntament ambla resta de la informaci relativa a la definici de projecte.

4.3. Tasques i subtasques

El desenvolupament del pla de treball d'un projecte significa tenir unes pautesen el cam que s'ha de seguir, per a assolir els resultats i estructurar una divisidel treball correcta i efica. Perqu el desenvolupament del pla sigui un xit,una de les claus s mantenir informats de l'evoluci del projecte tots els im-plicats. El fet de fomentar la implicaci de tots els participants en el projecteaugmenta la credibilitat del cap de projecte i del projecte per si mateix.

Quvolensaberelsclients? L'estat del projecte per a saber si es respecta elcalendari i el pressupost pactat. Tamb volen saber la probabilitat que ens ex-cedim de temps i despeses i, en general, anticipar-se a qualsevol problema quepugui sorgir. El client no vol sorpreses i n'hi ha prou, segons la durada delprojecte, d'un informe setmanal o quinzenal (en el cas de projectes grans).

El desenvolupament del pla de treball comporta dur a terme el projecte enmoltes tasques i subtasques (tasques subordinades a les tasques) i el repte prin-cipal del cap de projecte s esbrinar la relaci que hi ha entre les unes i lesaltres (si sn dependents o no) i coordinar de manera eficient i rendible coms'han d'executar i quan (seqncia).

Finalment, el disseny d'un bon pla (que tingui en compte tots els aspectes delprojecte, esdeveniments crtics, tasques o subtasques associades i la coordina-ci del conjunt) depn en bona part de les experincies anteriors, la nostra i lad'altres caps de projecte. Una bona estratgia passa per veure el projecte comun conjunt i dividir-lo desprs en diferents fases; no s complicat detectar-neles principals i identificar, des d'aquestes, les tasques i subtasques associades.


4.4. Estimaci de temps dedicat a les activitats

Una vegada tenim la totalitat de les activitats que cont el projecte, s a dir,una llista amb tot el treball que hem de dur a terme detallat, hem de fer unaestimaci del temps que considerem que es destinar a cada activitat.

En els primers projectes, sempre s un problema fer un clcul estimat de leshores que es pot trigar a fer una determinada activitat. En aquests casos, podemtenir en compte les tcniques segents, que ens ajudaran a estimar la duradade les activitats:

HistorialpreviSi hem treballat en algun projecte similar abans, mirarem els documentsgenerats per al pla de treball per a veure quant havem previst que es de-dicaria a les diferents activitats i quant s'hi va dedicar finalment.

AnalogiaEncara que no s'hagi fet una activitat exactament igual, potser s'ha treba-llat en un projecte que tenia una activitat similar a aquesta la durada dela qual estimem ara.

Per exemple, l'activitat consisteix a fer una animaci amb Flash. En un antic projecte, unade les activitats consistia a fer una animaci amb Director. Encara que no s la mateixasoluci tecnolgica, per analogia podem mirar el temps que triguem a fer-ho i estimarun temps proporcionalment similar.

RtioPodem aplicar aquesta tcnica quan hem fet una activitat similar a aquestala durada de la qual estimem ara, en un projecte d'una altra dimensi.

Imaginem-nos que en l'anterior projecte havem de fer deu grfics i hi triguem cinquantahores. Si en el projecte actual n'hem de fer cent de similars, per proporci, podem estimarque hi trigarem cinc-centes hores.

Opinid'unexpertMoltes vegades s'ha d'acudir a un expert intern o extern (la primera vegadaque s'usa una nova tecnologia). Aquest expert ens pot donar pistes deltemps que es pot trigar a fer una activitat determinada.

AfegirhoresdecontingnciaS'usa per a reflectir la incertesa o el risc associat a les estimacions. Si te-nim una activitat no gaire ben definida, hi podem afegir fins i tot unacontingncia del 50%. Si l'activitat s molt clara, hi podem afegir una con-tingncia del 10%. En casos de projectes molt similars a d'altres que ja hemfet, a les tasques s'hi pot aplicar aquesta contingncia del 10%.

Afegireltempsdegestideprojecte


En general, el 15% de les hores que es dediquen a un projecte han de serde gesti.

Per exemple, si tenim un projecte estimat en dotze mil hores (de set o vuit persones),veiem que el 15% correspon a mil vuit-centes hores, de manera que necessitarem un capde projecte amb dedicaci total al projecte.

FerlesestimacionsenhoresLa primera estimaci de durada que assignem a una tasca l'hem de feren hores, ja que s la millor manera de tenir una dimensi clara del quepodem trigar a fer-la. Posteriorment, aquestes hores les transformarem entemps (segons quantes persones fan la tasca, amb quina jornada laboral,etc.).

Una vegada s'han decidit, utilitzant totes les tcniques d'estimaci iels propis coneixements tecnolgics que t el cap de projecte, les ho-res que es dedicaran a cada activitat (de manera estimada), en la llistad'activitats que s'ha generat prviament s'hi ha d'afegir el temps de cadaactivitat.

Una vegada tenim la durada de totes les activitats, s'ha de calcular el tempsaproximat que es dedicar a la gesti. S'acostuma a calcular que s'hi dedicaaproximadament entre un 10% i un 15% del total d'hores de producci delprojecte (sobretot en els projectes mitjans i grans). Aix no implica que tota lagesti la faci el cap de projecte. Els responsables d'rees tamb poden fer unapart d'aquestes tasques de gesti.

Amb tempsdedicata lagesti no ens referim noms a la creaci i gestidel pla de treball. Les reunions amb el client, amb els responsables d'rea, elcontrol dels guions i de l'aven del projecte, etc., tamb sn activitats prpiesde la gesti del projecte.

4.5. Relacions i dependncies entre activitats

Una vegada tenim clares les activitats del projecte i les durades estimades, hemde veure les relacions que hi ha entre aquestes activitats. L'imprescindible sdelimitar totes les precedncies.

Amb precedncies ens referim a les activitats que s necessari que estiguinacabades abans que se'n comenci una altra. Per a aix, ens hem de fer, per atotes les activitats, la pregunta segent: per a comenar aquesta activitat, ne-cessitem que n'estiguin acabades prviament d'altres? En cas afirmatiu, mira-rem quines i les marcarem com a precedncies de l'activitat en concret.

Tipus de tasques que inclou la planificaci segons les dependncies que tenen:


Tasquesparalleles: es poden dur a terme alhora sense obstaculitzar elprojecte. Poden tenir diferents dates de comenament i acabament.

Tasquesdependents: sn aquelles que no poden comenar fins que noocorri una cosa que est prevista. Tasques o subtasques que no es comen-cen fins que una o diverses tasques prvies no s'han acabat.

Tasquespredecessores: una tasca que s'ha d'acabar abans que es puguicomenar la segent.

Fites: acabament de tasques, no requereixen forosament temps o pressu-post. No tenen associat sempre un lliurable. Les fites sn importants perals membres de l'equip del projecte, ja que marquen el cam que s'ha deseguir i els xits parcials. Les fites permeten que l'equip spiga que el pro-jecte progressa segons el que s'ha previst.

4.6. Aprovaci de la planificaci

s recomanable, una vegada acabada la planificaci, posar-la en com amb elclient i amb la resta de provedors, si n'hi ha, perqu totes les parts implicadesl'aprovin. L'objectiu s arribar a un consens sobre les diferents fites intermdi-es, sobre les dates dels lliurables i sobre els compromisos adquirits.

Un factor molt important de la bona marxa del projecte s la implicacidelclient. Alguna de les tasques del projecte depenen de dades, documentaci oinformaci que ha de proporcionar el client o de decisions que ha de prendresobre el projecte, com ara aprovaci de la funcionalitat, de l'interfcie grfica,de la interactivitat, etc.; per aix, el coneixement de quan ha de lliurar la in-formaci o de quin moment s'espera que prengui una decisi s vital per a labona marxa del projecte.

s igual d'important la implicacidelsprovedors. Si en el projecte participendiferents provedors, el fet d'acordar la planificaci s clau per a garantir elcompliment de la planificaci del projecte.

4.7. La posada en marxa

Desprs de la planificaci detallada i la revisi, passem a l'execuci o posa-da en marxa del projecte. S'ha de consultar el pla de producci per a seguirla seqncia de tasques i per a assignar-ne als participants (components del'equip de treball).


5. Seguiment del projecte

Desprs de posar en marxa un projecte cal gestionar el pla de treball. Encaraque sembli contradictori, ats el treball que comporta fer una planificaci, sino l'adaptem a la realitat a mesura que avana el projecte, es converteix enuna eina intil.

5.1. El seguiment i control d'un projecte

Una vegada comenat el projecte, la tasca principal del cap de projecte s ava-luar-ne i gestionar-ne el progrs. Un director o cap de projecte efica s aquellque n'examina totes i cadascuna de les tasques i subtasques fetes fins ara, elprogrs fet en el temps previst, l'encavalcament de tasques i com encaixen en-tre si, quines modificacions s'han de fer i com s'han de fer, els problemes quepoden sorgir, el control del pressupost i la motivaci dels empleats.

Vegem en una llista una srie de responsabilitats:

Anotar o registrar qualsevol variaci respecte al desenvolupament i la pla-nificaci d'un projecte.

Modificar la descripci de les tasques segons les necessitats i a mesura queprogressi el projecte. Quan el projecte es desvia, cal corregir tot seguit qual-sevol tasca i mantenir-se dins dels lmits de temps i pressupost.

Acompanyar els membres de l'equip, treballar-hi, construir un ambientd'equip, oferint crtiques bones i dolentes, escoltant-los i dotant-los de res-ponsabilitat.

Controlar l'mbit del projecte, assegurar-se que s'empren els recursos ne-cessaris.

Assegurar-se que se superen eficament els obstacles.

Mantenir bones relacions amb els nostres superiors i el client, mantenir-losinformats, evitar-los les sorpreses i estar pendents de les seves reaccions.

5.2. El pla de treball, una eina viva

La planificaci d'un projecte s una eina que ens serveix per a organitzar eltreball i l'equip, per no sempre t modificacions. Perqu sigui til, hem d'anaractualitzant aquest pla de treball a mesura que avana el projecte. s recoma-


nable gestionar el pla de treball com a mnim una vegada a la setmana. Quanho fem, hem d'identificar quines activitats s'han completat durant la setmanai actualitzar el pla de treball perqu es vegi clarament que estan acabades.

Quan fem revisi del pla de treball, hem d'indicar de manera clara aquellestasques en qu hi ha algun problema i aquelles que han requerit menys tempsdel que s'havia previst, ja que poden influir en tasques dependents.

Per exemple, veiem que l'activitat 3, que tenia una durada estimada d'aproximadamentquatre dies i mig, ja est acabada al 100%. En aquest cas, si aquesta activitat era prede-cessora d'una altra, aquesta altra podr comenar abans.

5.3. Activitats problemtiques, cam crtic

Quan fem la revisi, hem de veure si hi ha activitats que haurien d'estar aca-bades, per que no ho estan, i com afecta aquest retard al global del projecte.

En aquests casos, el cap de projecte ha de parlar amb els membres de l'equipque estan assignats a aquestes activitats per a veure quin s el problema ol'origen del retard. Pot passar que hi hagi hagut un problema o que l'estimacifos errnia. Al costat de les persones implicades s'ha de determinar quanttemps addicional es necessitar per a completar l'activitat i actualitzar el plade treball segons aquest temps afegit.

Una vegada actualitzat el pla de treball, s'ha d'avaluar si les modificacions im-pliquen algun canvi considerable en la durada i el cost originals. Probablementhaurem de retallar el temps que es dedicar a alguna activitat futura perququadri el pla de treball amb la data d'acabament fixada.

La metodologia ms utilitzada per a aquesta finalitat s el mtodedelcam

crtic1, que representa grficament les activitats i les dependncies que t ambun graf.

Un graf representa grficament un conjunt de punts (anomenats nodes) unitsper lnies (arestes). Els grafs permeten estudiar les interrelacions entre activitatsque estan en interacci, i representen els nodes, les activitats i les arestes deles dependncies entre aquestes interrelacions.

(1)Critical path method.


Exemple de graf de cam crtic

No solament s'anomena cam crtic el mtode sin tamb la srie d'activitatsexplicades des del comenament del projecte fins a l'acabament, que no tenenflexibilitat en el temps d'execuci, per la qual cosa qualsevol retard que tinguialguna de les activitats de la srie provoca un retard en tot el projecte.

Saber el cam crtic permet gestionar adequadament els retards possiblesi ens permet saber el marge de qu disposem per a corregir-los.

5.4. Resultats i tasques d'un projecte

Una de les dificultats en relaci amb la consecuci dels objectius en un projectes centrar-se en excs en les tasques que cal fer en lloc dels resultats que s'hand'aconseguir. Un bon cap de projecte ha de tenir sempre la vista posada al finaldes del comenament del projecte; d'aquesta manera, totes les activitats delprojecte estaran relacionades des del principi amb el resultat buscat i totes lesdecisions que es prenguin es prendran amb ms probabilitat d'assolir el finaldesitjat.

El resultat d'un projecte s quantificable, s'ha d'assolir en un perode determi-nat i amb un cost especfic; per aix un bon mtode de treball s partir de ladata lmit del projecte i treballar enrere fins al present, determinant les tasquesi subtasques que s'han de dur a terme.


6. El pressupost

Si b s cert que durant totes les fases del projecte s'ha de tenir molt presentque l'objectiu de qualsevol empresa s satisfer les expectatives del client ambun producte adequat i de qualitat, no s'ha de descuidar que aquest treball ha degenerar uns beneficis econmics per a l'empresa. Per aquesta ra s necessarisaber trobar el millor balan entre el servei ofert i el cost que representa.

s convenient tenir en compte que l'expressi client per satisfer s tan vlida pera empreses que fan serveis per a tercers com per a empreses que desenvolupentreballs per a l'empresa mateixa, sia perqu es tracta de projectes interns (perexemple, una intranet per a una empresa feta pel seu equip web) o perquaquesta empresa distribueix directament els seus productes (editorial que creaels seus propis ttols en CD-ROM). L'important s que, en qualsevol dels casos,s necessari mantenir un control estricte de qualitat, de calendari i econmic.

La majoria de temes econmics se solen tractar abans del comenament ma-teix del projecte, s a dir, durant l'elaboraci del pressupost per al client o enels primers passos del pressupost, per qualsevol incidncia en el projecte pottenir repercussions directes o indirectes sobre qestions econmiques.

A continuaci recordarem el concepte de pressupost. Veurem per qu es fa ien descriurem algunes tipologies. Tamb analitzarem alguns dels factors ques'han de tenir en compte quan fem un pressupost.

6.1. Qu s un pressupost

Per definici, un dels elements que caracteritzen un projecte s que disposad'un pressupostpreestablert; per tant, s important delimitar exactament qusignifica la paraula pressupost en el context d'un projecte.

El pressupost d'un projecte s la quantitat econmica que les parts (cli-ent i provedor) pacten per fer un producte o servei determinat s a dir,el cost que tindr per a un client l'elaboraci del projecte en qesti perpart d'un provedor concret i en un lmit de temps determinat.

El document de pressupost s el document que s'ha de lliurar al client en qu esdescriuen les tasques implicades en l'elaboraci d'un projecte i que condueixa la presentaci d'una quantitat econmica.


6.2. Necessitat del pressupost

L'objectiu d'elaborar un pressupost s el de tenir una quantitat econmica dereferncia acceptada pels actors implicats en un projecte.

En la majoria dels casos, el client sollicita al provedor una estimaci del costglobal que comporta obtenir el producte o servei, i poques vegades, tret que hihagi una relaci de confiana entre les parts, es factura per hores o per jorna-des. La frmula de cobrament per hores se sol utilitzar per a treballs puntuals

o fcils de quantificar i tarifar2.

El cobrament per jornades normalment es fa per a tasques de durada mitjana,com per exemple certes accions espordiques d'actualitzaci o mantenimentde materials com ara modificar la programaci d'una pgina web.

(2)Enregistrament de locucions, di-gitalitzaci de vdeos, etc.

Com s'ha comentat, hi ha certs casos quantificables en qu s tan possible tre-

ballar amb pressupostos globals com fer-ho per unitat3, per el resultat esperats el mateix: tenir una quantitateconmicadereferncia.

6.3. Tipus de pressupostos

Depenent de l'origen d'un pressupost, podem determinar diverses tipologiesde documents de pressupost: segons l'origen, segons l'estat, la filosofia, durada,destinaci, l'mbit, etc. En realitat es tracta d'una referncia, ja que es podriendeterminar tantes categories com criteris nous pogussim establir.

Documentsdepressupostsegonsl'origen

Asollicituddelclient: el client sollicita el document per a prendre ladecisi final, de manera que aquest document ha de ser impecable, tantdes del punt de vista formal com del de contingut. Moltes vegades no esdisposa d'una quantitat de referncia proporcionada pel client, per la qualcosa hi ha provedors diferents que poden presentar pressupostos (quan-titats econmiques) realment molt diferents.

Peraqualificar-se: no el sollicita el client, per el provedor sap o intu-eix les seves possibles necessitats; per tant, es presenta amb intenci dedespertar l'inters del client.

Comadocumentintern: no el sollicita el client, per s'elabora com aelement de control i gesti intern davant d'un projecte; s en casos en quel client nicament est interessat en la quantitat econmica.

Accsaunconcurs: el client estableix un concurs, amb la qual cosa elsprovedors interessats presenten la seva oferta. Normalment en els orga-nismes i les entitats de carcter pblic els concursos es publiquen en els

(3)Components maquinari, seqn-cia de vdeo, animaci, pginesredactades, etc.


butlletins oficials corresponents; les necessitats solen estar definides en unplec de prescripcions i les quantitats econmiques estan totalment deli-mitades.

Documentsdepressupostsegonsl'estat

Enrevisi: quan el document es troba en el procs de revisi, sia intern,en l'empresa mateixa, o extern, per part del client.

Definitiu: si ja est acceptat i validat internament i pel client.

Documentsdepressupostsegonslafilosofia

Tancat: no hi ha marges per a ampliacions ni variacions econmiques.

Obert: s'estableixen uns marges de referncia, per amb possibilitatsd'ampliaci per acord mutu.

Documentsdepressupostsegonsladurada

Limitada: se'n sap per endavant la durada i la nulla possibilitat decontinutat futura.

Prorrogable: es determina un temps a partir del qual es pot renegociar elcontracte o prorrogar la validesa del pressupost. No es preveu la possibili-tat d'un contracte de pressupost per a un projecte "indefinit", ja que cadaprojecte t una durada finita.

Documentsdepressupostsegonsladestinaci

Versiinterna: versi del document de pressupost amb les hiptesis delsdiferents escenaris econmics i l'expressi dels marges comercials. s elque s'utilitza per a decidir quina opci es presentar al client.

Versiperalclient: document en qu es presenten quantitats finals des-tinat a lliurar-lo al client.

Documentsdepressupostsegonsl'mbit

Global: si el pressupost afecta a tot l'mbit d'actuaci de les companyiesimplicades (mbit geogrfic, de sector econmic, etc.).

Localosectorial: en cas que l'acord afecti nicament sectors localitzatsd'alguna de les empreses implicades.


Com hem comentat, les possibilitats d'elaborar classificacions sn prctica-ment illimitades; aqu hem volgut presentar algunes de les opcions ms co-munes.

6.4. Factors que s'han de tenir en compte en un pressupost

En elaborar un pressupost sempre compensa estimar els recursos econmicsnecessaris a l'ala. Els motius sn els segents:

Per molta informaci que es tingui, no s'haur tingut en compte tot.

Malgrat la precisi dels clculs, del marge de tolerncia o del tipusd'obstacles que s'han previst, s possible que fem curt en les estimacions.

En un ambient comercial, social i tecnolgic en canvi continu, hemd'incloure en el pressupost un espai ampliable per a fer front a les despesesaddicionals que es presentin.

Com a conclusi:

El pressupost ha de ser flexible i ha de tenir un marge destinat a preveurepossibles errors d'estimaci a l'hora de planificar.

El pressupost pot ser una mica ms ampli del que indiquin els nostresmillors clculs.

L'impacte acumulat per a calcular a la baixa el temps necessari pot fer en-filar el cost del projecte.

A l'hora de calcular el cost econmic s fonamental:

Evitar la tendncia de calcular a la baixa el temps que necessiten els mem-bres de l'equip per a fer un treball.

No descuidar-se dels pressupostos dels subcontractats o externs; si treba-llen amb una tarifa fixa s fcil de calcular, per qu ocorre amb el tempsemprat en reunions amb el subcontractat, el seguiment del seu treball, lestasques administratives, les trucades i els correus electrnics?

Sollicitar ajuda a tot l'equip; no calcular nicament des de la prpiacompetncia.

Tenir present que durant un projecte sobrevindr ms d'una crisi (pagar uncost desorbitat per un recurs, treballar hores extres, buscar ajuda externa)i cal estar preparats per a aix.


6.4.1. Models per a elaborar un pressupost

Per a elaborar el pressupost podem utilitzar algun dels models segents:

PressupostardedaltabaixDes d'aquest enfocament, se sondeja la direcci de l'empresa i es fa unarecerca massiva de projectes antics amb caracterstiques similars a l'actual.Es recopilen les despeses associades a cada fase, les tasques i subtasques.Per a afinar una mica ms, el cap de projecte involucra els membres del'equip i aconsegueix la seva estimaci del temps (i dels costos) de les tas-ques i subtasques especfiques. Finalment, es corregeix l'estimaci iniciali es presenten les dades a la direcci, tenint en compte un marge de segu-retat en l'elaboraci dels pressupostos.

PressupostardebaixadaltDesprs d'elaborar la planificaci, l'equip de desenvolupament es reuneixper a estimar el pressupost requerit per a cada tasca i subtasca inclosa enel projecte. Se supervisen els canvis entre tasques des que es comena elprojecte per a continuar elaborant i contrastant el pressupost, que s'ha desotmetre a l'aprovaci de la direcci de l'empresa. A mesura que el projecteavana i l'equip progressa, les tasques es resolen de manera ms efica, laproductivitat s ms gran i els costos, ms baixos. La implicaci s unabona tcnica de gesti ja que el coneixement de cadascun dels passos ensdna el que s necessari per a elaborar un pressupost.Aquest model de clcul t molts avantatges (recopilar despeses de maneraprecisa i detallada) per tamb riscos, ja que si no s'hi inclouen les despesesde tots els elements, el pressupost se sortir del marge.

PressupostardedaltabaixidebaixadaltCombinar les dues tcniques s l'enfocament ms efica per a elaborar unpressupost. Requereix reunir totes les dades de direcci i sollicitar la con-tribuci dels membres de l'equip per a ajustar les estimacions adequada-ment.

Independentment de l'enfocament emprat, s necessari tenir en compte la di-ferncia que hi ha entre la jornada laboral i les hores que es treballen realment;cap membre de l'equip no ha d'estar vuit hores en productivitat constant. Iper aix cal afegir un 10% o un 15% ms a les estimacions pressupostries enprevisi del temps necessari per a completar les tasques.


Bibliografia

Referncies bibliogrfiques

Daccach, J. C. (2008). "Administracin de proyectos" [document en lnia]. Delta Asesores.

Gido, J.; Clements, J. P. (1999). Administracin exitosa de proyectos. International ThomsonEditores.

Lewis, J. P. (1995). Planificacin, programacin y control de proyectos. Barcelona: Ediciones S.

Mochal, T. (2000). Ten Step Project Management Process [document en lnia].

Perea Brand, J. (1996). Direccin y gestin de proyectos (2a. ed.). Madrid: Ediciones Dazde Santos, SA.

Gesti de projectesIntroduccindex1. El projecte i la gesti de projectes1.1. Exemples de projectes1.2. Projectes multimdia1.2.1. Tipologia dels projectes multimdia

1.3. Tipologia de projectes1.3.1. Segons la dimensi1.3.2. Segons el client

1.4. El triangle de la gesti de projectes1.5. Factors d'xit d'un projecte

2. Habilitats per a gestionar projectes2.1. Definici del projecte2.2. Planificaci del treball2.3. Administraci de contractes2.4. Administraci de provedors2.5. Administraci del pla de treball2.6. Administraci de situacions2.7. Administraci de l'abast2.8. Administraci de riscos2.9. Administraci de la comunicaci2.10. Administraci de la documentaci2.11. Administraci de la qualitat2.12. Administraci de les mtriques

3. La planificaci3.1. Etapes d'un projecte web

4. Metodologia de planificaci d'un projecte4.1. Definici dels recursos necessaris per a assolir els objectius4.2. Revisi de la definici del projecte4.3. Tasques i subtasques4.4. Estimaci de temps dedicat a les activitats4.5. Relacions i dependncies entre activitats4.6. Aprovaci de la planificaci4.7. La posada en marxa

5. Seguiment del projecte5.1. El seguiment i control d'un projecte5.2. El pla de treball, una eina viva5.3. Activitats problemtiques, cam crtic5.4. Resultats i tasques d'un projecte

6. El pressupost6.1. Qu s un pressupost6.2. Necessitat del pressupost6.3. Tipus de pressupostos6.4. Factors que s'han de tenir en compte en un pressupost6.4.1. Models per a elaborar un pressupost

Bibliografia

Mòdul 2. Gestió de Projectes

Documents

Transcript of Mòdul 2. Gestió de Projectes