calaix[À]gil.com

www.calaigagil.com

CAT | ESP | EN



Gestió del canvi en projectes tecnològics. Empoderar als membres de l'equip

ES / CAT

Que vol dir empoderar? Aquesta expressió s’ha d’entendre, no des d’una semàntica de poder, sinó de responsabilitat

descarrega la versió pdf d’aquest article


1. Empoderar els usuaris clau

Que vol dir empoderar? Aquesta expressió s’ha d’entendre, no des d’una semàntica de poder, sinó de responsabilitat. La responsabilitat de tots els actors del projecte és clau per a garantir un bon flux de les comunicacions, les relacions i l’acompliment dels objectius del projecte.

Els usuaris clau són un element especialment important per a garantir l’èxit final del projecte i dels seus productes. Un usuari clau que no assumeix les seves responsabilitats en el projecte pot generar seriosos problemes en la comprensió de la necessitat i de la solució, que poden acabar en fracàs o en la cancel·lació del projecte.

Metodologies tradicionals (i pesades) com PRINCE2 fa anys que són conscients de la importància de l’equilibri de responsabilitats entre tots els participants, i estableixen mecanismes de direcció, seguiment, acompliment de la qualitat i acceptació molt estrictes.

Amb l’aparició de marcs de treball àgils pot semblar que aquests aspectes són més laxes, i fins i tot podem pensar que són inútils, però això és un element més de confusió en la voràgine actual d’assimilació desordenada d’Agile.

En aquest sentit és important assegurar que l’usuari clau realment assumeix la responsabilitat que li pertoca. Les responsabilitats no es deleguen; la feina sí que pot delegar-se. És a dir: l’usuari clau ha d’assegurar-se que ell o una altra persona a la qual delegui acompleix les fites que se li encomanen. Però la responsabilitat en l’acompliment de les fites pactades serà de l’usuari clau i no dels delegats.

Coneixement del negoci

Una premissa important que proporciona tranquil·litat en la gestió d’un projecte és la tria encertada dels usuaris clau del projecte. Els usuaris clau els tria el negoci i no el projecte; i és responsabilitat seva fer una tria adequada i realista. Un usuari clau és una persona que, a banda de la seva feina habitual, dedica un temps (sovint considerable) en col·laborar en la definició de les necessitats, i en l’acceptació posterior dels resultats.

L’usuari clau és una persona que principalment:

*Coneix el negoci en detall *Ha de disposar d’aquest temps imprescindible per tal de tenir la interlocució necessària amb els equips del projecte

Clima de les comunicacions

Per poder assimilar tota la informació necessària per a dissenyar una solució completament satisfactòria hem d’assegurar un bon clima de comunicació amb aquests usuaris. Això només és possible si tenim en compte una sèrie de factors que han de quedar clars des del primer moment del projecte:

*La responsabilitat dels usuaris clau en el projecte *Les fites, les tasques, les reunions i, en definitiva, el pes d’aquestes responsabilitats per part de l’usuari clau *L’abast del projecte (que es fa i que no es fa)

En el punt anterior parlàvem que la principal responsabilitat de l’usuari clau és assegurar-se que l’equip del projecte entén la problemàtica a cobrir per la solució. En aquest sentit, hi ha alguns ítems que afecten la forma de comunicar o a “què es comunica” que sovint genera malentesos en l’equip del projecte. Per completar la llista anterior podem afegir que l’usuari clau ha de:

  • Ha de ser obert, pel que fa a la definició de la situació actual del flux de treball de la seva competència. Explicant la realitat del seu dia a dia de forma clara, suficient i completa.
  • Ha de ser pedagògic en les seves explicacions. L’equip del projecte probablement no coneix tots els detalls del seu flux de treball. L’usuari clau ha de focalitzar-se en assegurar que l’equip comparteix amb ell el detall de la problemàtica.
  • Ha d’entendre l’abast i els límits del projecte. Que es pot fer ara, que es pot fer més tard i que no es pot fer. L’usuari clau ha de tenir molt present l’abast del projecte que s’ha pactat, els límits de la tecnologia, els límits de l’organització i qualsevol altre factor que afecti el que ell entén com la solució ideal
  • Ha de ser conscient que l’organització és una maquinària complexa de múltiples parts. I la solució idònia per a ell pot ser un gran escull per altres àrees, departaments o persones de l’organització. El millor per a un departament no necessàriament ha de ser la millor de les solucions possibles

Un projecte és una acció d’equip en la que acostuma a participar un grup heterogeni de persones, amb diferents graus de coneixement o especialitat. És necessari generar un clima de transparència en el treball i assumpció de responsabilitats, per tal d’afavorir la generació d’un clima de confiança que faciliti la construcció de la solució idònia.

Parlar el mateix idioma (argot del negoci)

Tothom ha d’entendre el mateix respecte a l’abast i respecte al flux del negoci de l’usuari. L’equip del projecte i els usuaris han de parlar el mateix idioma. I l’únic idioma vàlid en aquest sentit és l’idioma del negoci, amb totes les seves particularitats i argot. Només així podem estar segurs que l’abast del projecte és ben entès per a totes les parts

2. Empoderar a l’equip del projecte

Un cop tenim empoderat a l’usuari clau, el següent pas és incloure’l dins de la dinàmica del projecte, i dotar a l’equip de les eines que facilitin la seva organització interna i la seva coordinació, un marc de treball que els permeti treballar de forma ordenada i racional, i un àmbit de decisió que els permeti ser operatius, eficients i autònoms.

Que coi és això “d’equip”?

Un equipo es un conjunto de pUn equip és un conjunt de persones que col·laboren per l’assoliment d’uns objectius comuns. Aquesta senzilla definició sovint és oblidada per passar a ser “un grup de persones que treballen plegades”. Perquè un “grup” passi a ser un “equip” cal que:

  • Treballin plegades: En contacte directe. Que es puguin parlar i que es coneguin
  • Responsabilitats clares: Perquè un grup sigui un equip, cada component ha de ser perfectament conscient de quin és el seu paper en l’equip
  • Tothom té alguna cosa a fer: Assumir responsabilitats significa ser conscients que tenim una missió en l’equip i que aportem un valor. En un equip no hi ha persones que van per lliure
  • Generen un clima constructiu i col·laboratiu: Tots els membres de l’equip expliquen obertament el que fan, i el que esperem dels altres. Presenten resultats, demanen ajuda, etc.

Para alcanzar este nivel Per assolir aquest nivell de col·laboració, l’equip del projecte ha de disposar d’espais i temps per assolir el clima necessari per arribar a acords interns i treballar col·laborativament i constructivament.

L’equip del projecte és quelcom més que un cap de projecte + constructors o proveïdors

L’equip del projecte són totes aquelles persones amb responsabilitat sobre la infraestructura, l’arquitectura i la qualitat. Tots ells formen part de l’equip del projecte. La complexitat de les organitzacions influeixen també en l’organització interna del departament tecnològic; on es creen subdepartaments especialitzats en certs aspectes del programari, maquinari, seguretat, processos o gestió.

Un element més de complexitat acostuma a ser l’externalització dels serveis, que afecta moltes operatives de l’àrea tecnològica, però especialment al desenvolupament de solucions. Arribant a l’extrem en què en l’àrea tecnològica s’adquireix un rol de lideratge de projecte, amb equips humans i recursos externalitzats.

Tots els membres del projecte tenen tasques assignades

Tothom ha de tenir una responsabilitat clara en el projecte; i es demana de tothom la màxima implicació en el projecte. Algunes persones pensen que participar en un projecte és “opinar”. Van, diuen el que els hi ve de gust dir, i marxen. S’ha d’evitar aquesta actitud.

Tota persona que participa en un projecte té una responsabilitat, i l’assumpció d’aquesta responsabilitat és deriva necessàriament en l’assumpció d’una sèrie de tasques assignades. Fuig dels opinadors sense feina en el projecte.

Els facilitadors també formen part de l’equip de projecte

Algunes organitzacions dediquen recursos a assegurar que el coneixement funcional i de negoci no es perd; de forma que aquest coneixement està en mans d’un equip de persones que vetlla per transmetre’l quan és necessari, i per la seva coherència situacional i evolutiva.

Aquestes persones també son part de l’equip del projecte. El cap de projecte necessita estar assessorat per algú amb una visió més transversal del negoci que els usuaris clau i que ell mateix. Per tal d’assegurar el millor possible que les situacions descrites són coherents amb aquest coneixement; i que les propostes de solució també són coherents des d’una perspectiva global.

Aquests facilitadors també poden exercir el paper de negociadors en situacions de conflicte. I de donar suport als usuaris clau en la presa de requeriments. Aquest equip requereix una formació molt específica, i de l’assumpció d’un rol molt concret. Aquestes persones han d’ocupar un lloc d’equidistància entre els interlocutors. I han de basar les seves intervencions en funció dels impactes sobre els processos de treball de l’àrea de negoci; o bé si generen conseqüències negatives fora de l’àrea destinatària del projecte. No prenen decisions unilaterals que afecten el projecte, i no són l’advocat de l’usuari.

Coneixement suficient del negoci

Un factor molt important correspon al fet que els caps del projecte, a banda del coneixement tecnològic suficient; i els coneixements de gestió del procés del projecte i dels equips; han de tenir un coneixement suficient sobre l’àrea de negoci i sobre l’organització per poder exercir la seva feina. Això implica no només conèixer el flux de negoci del departament en qüestió, sinó també conèixer “com parlen” en aquell departament.

Responsabilitat del cap de projecte

Els caps de projecte són els directors operatius del projecte. Tenen la màxima responsabilitat, i estan per a prendre decisions i cercar consensos. D’aquest fet ha de ser conscients tots els participants. L’objectiu de tot projecte és la creació d’un producte útil. I per aconseguir-ho comporta una acció contínua de negociació i consens, però per sobre d’això, comporta la presa de decisions que no sempre deixa content a tothom.

En aquest sentit el cap de projecte pren decisions en funció dels acords que negoci, interessos de tots els participants, i la mateixa organització. Prendre decisions no necessàriament significa l’establiment d’una jerarquia a l’intern de l’equip, on la figura màxima és el cap del projecte. Més aviat prendre decisions vol dir facilitar el clima òptim en l’equip perquè aquest protagonitzi les decisions i lideri les accions necessàries.

Això representa un canvi en el paradigma tradicional del cap de projectes, que passa a ser un facilitador més que un comandament. Això requereix confiança en l’equip, i proactivitat per part dels integrants. Un equip passiu no és un bon punt de partida per comprometre’s amb un pla conjunt. Cal pedagogia per motivar l’autoorganització necessària perquè l’equip sigui el motor del projecte de forma contínua. Les decisions no es prenen un dia D a una hora H. Es prenen cada dia, quan és necessari.

Canals clars per a rendir comptes

Relacionat amb el punt anterior, l’única forma de garantir que el projecte realitza les accions, i que aquestes són parelles amb les decisions que s’han pres, és establint un sistema d’informació o seguiment entre les persones que prenen les decisions. Els caps de projecte rendeixen comptes al grup de seguiment directiu que s’hagi establert.

Rendir comptes és l’acció de casar les decisions preses amb les accions realitzades en el projecte. I perquè això sigui coherent, les persones que prenen decisions i que tenen la responsabilitat, han de ser les mateixes que articulen el seguiment.

El cap de projecte no rendeix comptes a ningú més. L’equip directiu els protegeix per evitar que el projecte es vegi influït de forma externa. Sembla una obvietat, però molts projectes pateixen aquest tipus d’interferències i generen conflicte entre el que inicialment es decideix, i el que finalment es realitza.

El control de tots els aspectes de gestió

Per últim, un factor important correspon al control de les variables del projecte. L’atribució principal del cap de projecte és el control d’aquestes variables, i la llibertat suficient per poder prendre decisions. Si no es té aquest control, el cap de projecte no és un gestor, és una altra cosa.

Les variables sota control del cap de projectes són:

  1. Recursos interns, externs i proveïdors.
  2. Calendari i planificació del projecte.
  3. Pressupost, compres, contractacions, negociacions de les gestions del canvi, gestió de les limitacions pressupostàries, priorització
  4. Determinació de les normes de qualitat estàndards (les establertes per l’organització) i particulars (segons les particularitats del projecte): qualitat documental, flux de gestió, flux d’execució, qualitat del codi, qualitat del producte, flux de testing i política d’acceptacions

3. Les accions per fomentar el canvi en l’organització

Empoderar els membres de l’equip (inclosos els usuaris clau)

Per a què els diferents membres de l’equip assumeixin la seva responsabilitat, i treballin de forma coordinada entre si, cal proporcionar bàsicament quatre pilars:

  • Un espai de treball que faciliti l’agilitat
  • Una estructura de relacions, que respongui a qui és responsable de què, o qui fa què
  • Un flux de treball, que ajudi a l’equip a dur a terme les seves tasques en el projecte
  • Uns “moments” o fites, en què l’equip es coordina, mostra els avenços, resol problemes, etc

L’agilitat com a eina d’empoderament

Per aplicar agilitat en processos complexos, on intervenen sovint un gran nombre de persones, és necessari ser conscients que les operacions de gestió (el management) és massa important per deixar-ho només en mans de gestors. Hem de transmetre la idea que la gestió també és una tasca d’equip, i que el cap del projecte focalitza els seus esforços en crear el clima necessari per al foment de la gestió eficient i la creativitat, (cuida un jardí).

Es tracta de trobar un clima de treball en què l’equip és l’autèntic protagonista sobre el “com” es fan les coses al seu intern. I aquí el cap del projecte és un membre més en l’equip.

Les principals barreres en l’adopció de l’agilisme són diverses, però es poden destacar:

  • Resistència general al canvi en l’organització
  • Possibilitats reals de fer efectiu un canvi cultural en l’organització
  • Aplicar conceptes àgils en un sistema organitzatiu anti-àgil, per causes tecnològiques, per l’acompliment de normativa o burocràcia externa o de la mateixa organització, o pel sistema de relacions entre departaments i persones de l’organització

Que és una organització anti-àgil? Una organització anti-àgil és aquella en què els seus elements de coordinació interna i productius s’articulen entorn de dos elements característics: Burocràcia i jerarquia. De forma que, per tal de dur a terme qualsevol acció prevista a l’organització, aquesta és avaluada a través d’un procés formal o informal que la pauta i la delimita (burocràcia), i dona resposta a interessos de grups que coordinen la seva idoneïtat, abast i temporalitat, i que tenen l’atribució a diferents escales de validar o no la seva conveniència (jerarquia). Amb l’existència d’un nucli que centralitza les decisions, i que estén el seu poder a tota l’organització (Taylorisme)

Aquest tipus d’organització són vistos com una màquina; capaç de fer un nombre concret d’accions, i d’una forma determinada, que a més tendirà sempre a ser la més eficient possible. Per assolir aquest màxim d’eficiència, mostra una tendència en especialitzar-se per seccions (o ninxos). Els ninxos actuen com a engranatges independents que tenen visió només d’una part de la cadena de valor de l’empresa, i on s’estableixen vies estrictes de contacte amb altres engranatges.

Quan aquest tipus d’organitzacions és sorpresa amb canvis tecnològics, humans, organitzatius, polítics, pressupostaris, i un llarg etc. que posen en perill el seu statu quo actual, necessiten adaptar-se. L’adaptació en una organització-màquina és possible, però és lenta i sovint desemboca en adaptacions parcials que no cobreixen completament allò que les va forçar a canviar.

Organización-máquina

Una organització àgil és aquella en què els engranatges tenen tots ells (o gran part) una visió completa de la cadena de valor de l’organització. Són autoorganitzades i tenen capacitat de decisió. El centre de l’organització no és vist com un centre de poder, sinó com una guia en la direcció. La capacitat d’adaptació d’aquestes organitzacions vénen determinades per la seva flexibilitat interna i externa. Els diferents nuclis (o cèl·lules) operatius poden créixer, disminuir i alterar la seva organització interna i especialització. Poden aparèixer noves cèl·lules per a cobrir noves necessitats i adaptar-se als canvis, siguin els que siguin.

Definició de l’estructura de relacions

Una estructura de relacions documentada és un esforç per explicar de forma gràfica les relacions entre els diversos membres de l’equip, focalitzades en l’assumpció de responsabilitats. Al gràfic següent mostrem una proposta d’estructura de relacions, amb tots els grups i persones que hi intervenen en un projecte:

Estructura de relaciones

En aquest gràfic podem descriure els rols següents:

El Cap de projecte correspon a la figura que, en última instància, té la responsabilitat principal d’assegurar el contacte continuat de tots els membres de l’equip. Aquestes responsabilitats les podem resumir de la forma següent:

  • Assegurar que tots els membres assumeixen les seves responsabilitats
  • Assegurar que l’equip entén el marc de treball i que el segueix. Això inclou principalment el cicle de vida, les fites de la gestió i l’execució del projecte, i la qualitat
  • Assegurar que l’equip compren la necessitat de pautar l’execució, prioritzar les tasques i seguir un pla consensuat
  • Assegurar que s’acompleixen els barems de qualitat que l’equip ha determinat per al projecte

El Grup de Seguiment és l’òrgan que té la funció principal d’avaluar el seguiment del projecte, en funció a la informació que l’equip, i principalment el cap de projecte li trasllada. Pren decisions i ajuda a la priorització dels objectius, i a la resolució dels problemes i riscos que siguin de la seva competència

Idealment, els membres del grup de seguiment han de veure reflectits tots els interessos del projecte i de l’organització. Així doncs, han de veure’s cobertes les visions tecnològiques, però també la visió del negoci i dels constructors/proveïdors.

La PMO és l’òrgan que dóna suport a l’equip de projecte per tal que s’acompleixin els requeriments de qualitat tant pel que fa al producte del projecte, com per al mateix procés. La seva vinculació amb el projecte no s’ha de confondre amb una auditoria. Son part de l’equip i tenen tasques i responsabilitats assignades. Per tant col·laboren amb l’equip en l’assegurament de la qualitat del projecte.

L’Usuari clau és una figura primordial en l’equip; i té un nivell de participació en què va més enllà de ser un facilitador estàtic d’informació del negoci. Ajuda a l’equip a prioritzar els objectius. Ajuda a definir la profunditat (el detall) dels objectius del projecte i del seu abast. Ajuda a resoldre els problemes, i a preveure’ls, identificar-los i mitigar-los. I per sobre de tot ajuda a validar que el resultat del projecte acompleix les expectatives de qualitat de forma iterativa i incremental. I per això es compromet a treballar amb el producte des del primer moment

Els Facilitadors, tal com hem explicat en seccions anteriors, es constitueixen com un pont en la comunicació entre els usuaris clau i l’equip del projecte. Els facilitadors tenen sentit quan la informació de negoci necessària per a l’execució del projecte és o molt complexa, o molt dispersa. Si no és així, no hi hauria d’haver cap inconvenient en què tecnòlegs i usuaris entrin en contacte directe. Moltes organitzacions han arribat a la conclusió que tecnòlegs i usuaris mai podran entendre’s. És una visió típica dels anys 90, que actualment encara perdura.

Els Caps de Projecte proveïdors són els responsables de l’operativa de la construcció / implantació / adquisició per part dels constructors o proveïdors assignats al projecte. Tenen un paper molt semblant al Cap del Projecte general, però el seu àmbit de responsabilitat se centra en el seu equip de construcció. Sovint l’equip de construcció es troba en les instal·lacions del proveïdor, i és poc conegut i poc accessible per l’equip del projecte. El Cap de projecte proveïdor fa de passarel·la entre els desenvolupadors i la resta de l’equip.

Per últim, aglutinem la resta de membres de l’equip sota l’epígraf de Col·laboradors. Un col·laborador és aquell que dins de l’equip desenvolupa un o més rols que són necessaris per poder executar alguna de les tasques del projecte. En l’àmbit d’un projecte, totes les tasques necessàries necessiten ser cobertes, o bé liderades per un membre de l’equip. No poden haver-hi tasques sense un responsable assignat.

Com hem dit abans, col·laborar implica necessàriament desenvolupar una tasca dins del projecte. Una tasca és un treball que té com a resultat final un subproducte útil per al producte del projecte o per a l’equip (un informe, una acció d’R+D, codi, etc.). No és un subproducte útil per al projecte una opinió no contrastada.

Tampoc és un subproducte útil per al projecte l’auditoria d’una acció ja realitzada en l’intern de l’equip. Un NOK d’un subproducte finalitzat és un trauma en el projecte. Significa que els creadors del subproducte no han entès les regles. Però també significa que els auditors han actuat de forma reactiva en la construcció del subproducte. Si una auditoria ha de formar part de les tasques del projecte, significa que els auditors formen part de l’equip del projecte. I significa que són ells qui lideren les accions necessàries per assolir un OK en el subproducte.

Els moments que acoten el projecte: El kickoff i el tancament del projecte

De totes les fites de govern d’un projecte, podem determinar dues que són especialment importants. Aquestes són:

  • L’inici de projecte, o Kickoff
  • La finalització del projecte, o Tancament

El kickoff

El kickoff és una acció en forma d’una sessió, en què tots els membres del projecte, i les persones impactades o interessades es reuneixen i exposen tots els aspectes clau, amb l’objectiu d’obtenir una llum verda per part de tots els assistents, que permeti l’inici de les accions d’execució del projecte

Però per arribar al dia en què es realitza una sessió, que acaba en l’acceptació de tot allò que s’exposa, el cap de projecte ha de realitzar una feina ingent destinada a assegurar aquest resultat. Aquest procediment, descrit com procediment de Inici del projecte, el veurem tot seguit

De forma resumida, el procés d’inici de projecte té com a objectiu principal definir en detall els objectius, l’abast, i la relació dels membres de l’equip de projecte, i les seves responsabilitats. Un kickoff que defineix amb èxit aquests aspectes és una molt bona manera d’iniciar un projecte. De fet, molts projectes fracassen per:

  • Falta d’acord sobre el seu abast
  • Mancança d’una visió clara dels objectius i beneficis que s’obtenen amb el producte del projecte
  • Identificació errònia de l’impacte del producte de projecte en el departament destinatari; o en altres departaments
  • Selecció errònia dels membres de l’equip del projecte
  • No identificació, o identificació errònia de les responsabilitats dels membres de l’equip del projecte
  • No identificació, o identificació errònia dels principals riscos del projecte, ni proporcionar el detall suficient de plans de mitigació d’aquests riscos

Per assolir un relat que sigui acceptat per a totes les parts en una sessió d’inici de projecte, cal abans encetar un procés que té com a finalitat determinar els objectius, l’abast, les claus d’èxit, la planificació inicial / desitjada, l’organització de l’equip, les responsabilitats i els riscos

Això requereix reunions amb els usuaris clau, amb els proveïdors i amb altres àrees afectades; i negociar amb ells una visió clara i consensuada del projecte i del producte resultant. Un cop fet això, la sessió de kickoff es converteix en una coreografia de final controlat que té com a únic objectiu explicitar aquest consens entre totes les parts.

El Tancament

Quan podem determinar que un projecte s’ha finalitzat?

  • Quan el producte del projecte entra en productiu?
  • Quan els usuaris clau donen el seu vistiplau?
  • Quan el(s) proveïdor(s) finalitzen el seu contracte?

Igual que l’inici del projecte és una acció de consens que dóna el tret de sortida a l’execució, la finalització del projecte no pot ser d’una altra manera. Un projecte finalitza únicament en dos escenaris possibles:

  • L’equip del projecte formalitza l’avortament del projecte
  • L’equip del projecte formalitza la finalització del projecte

El que està clar és que l’únic estament que té la prerrogativa de finalitzar un projecte és el mateix equip del projecte. De forma ordenada, consensuada i documentada. En ambdós casos és necessari exposar la situació final del projecte i del producte del projecte, Les accions de continuïtat, garantia i manteniment que es desprenen, i la valoració respecte a la satisfacció del procés, del producte i respecte a les lliçons apreses.

Les principals fites en la gestió d’un projecte

A tall de resum, les principals fites o “moments” en un projecte poden resumir-se en el diagrama següent:

hitos en la gestión

Inici de projecte

L’inici del projecte és un procediment que té com a objectiu assentar les bases del govern i de l’execució del projecte. Per aconseguir això cal establir una sèrie de premisses del projecte que podem resumir en la llista següent:

  • Coneixement per totes les parts del propòsit del projecte, i acceptació d’aquest propòsit
  • Determinar els objectius que persegueix acomplir amb el producte del projecte, a través del seu ús o l’impacte que en tindrà. Així com l’abast
  • Consensuar una planificació, un marc pressupostari i una disponibilitat de recursos materials i humans
  • Tancar un model organitzatiu per al projecte, amb rols i responsabilitats clares
  • Conèixer els riscos o impediments per la construcció del producte del projecte, o que la generació d’aquest producte pot causar

Per la determinació i detall de tots aquests aspectes es treballa amb tots els implicats seguint el flux de treball següent:

Inicio de proyecto

  1. Preparatòria: En aquesta fase el Cap de projecte que el recepciona realitza una sèrie de tasques destinades a obrir els sistemes de gestió i documentals del projecte
  2. Pre-kickoff: Aquesta fase consisteix en una o diverses sessions amb els principals interessats del projecte (de negoci i proveïdors) amb l’objectiu de documentar de forma completa el kickoff, de forma que incloguin tots els aspectes importants necessaris per a l’execució del projecte.
  3. Sessió de kickoff: El kickoff es configura com una sessió presencial on tots els interessats en el projecte ja han treballat els acords que es presentaran allà. I per tant ha de ser una representació d’un acord previ. Basat en una presentació de kickoff del qual veurem el contingut en seccions posteriors
  4. Post-kickoff: En la fase de post-kickoff es rubrica l’acord amb la distribució d’una acta, que inclou tots els acords presentats a la sessió. Aquest punt dóna el tret de sortida a la conformació oficial de l’equip de projecte; amb la disponibilitat de tots els membres de l’equip; i a l’inici de les tasques d’execució.

Cierre de proyecto

Tancament de projecte

Un projecte acaba quan els membres de l’equip determinen que s’han assolit els objectius suficients establerts a l’inici del projecte; o bé quan decideix avortar-lo per causes justificades.

Igual que a l’inici del projecte, la finalització requereix la consecució d’una sèrie d’activitats que tenen com a objectiu el tancament ordenat de les activitats, l’assegurament de l’explotació del producte del projecte, l’avaluació de la satisfacció de tots els implicats, i l’avaluació dels beneficis obtinguts pel producte del projecte

  1. Documents de continuïtat: El projecte no acaba quan el producte es troba en explotació, si no quan es veuen acomplerts tots els requeriments documentals i informatius necessaris per a l’explotació, el manteniment i el coneixement dels usuaris. Això inclou:
  2. Manuals d’usuari i pla de formació
  3. Documents de pas a operacions
  4. Documents de pas al servei de manteniment
  5. Acords i activació del servei de manteniment, llicenciament, evolutiu, adaptatiu i correctiu
  6. Reunió de tancament: La reunió de tancament, igual que en l’inici del projecte, té com a objectiu que totes les parts mostrin un acord sobre els objectius acomplerts en el projecte, les vies d’evolució possibles, les lliçons apreses, la valoració en funció dels objectius acomplerts i la satisfacció, els acords respecte a la garantia del producte del projecte i els canals de manteniment
  7. Reunió de lliçons apreses: Juntament en la reunió de tancament, o bé en reunió a banda, l’equip reflexiona sobre la satisfacció tant des de la perspectiva del producte aconseguit, com del procés de coordinació del projecte. En aquesta reflexió l’equip documenta una sèrie de lliçons apreses que poden servir per canviar aspectes del procés en futurs projectes A més, en aquest punt, l’equip confecciona la forma en què s’avaluarà la satisfacció de totes les parts involucrades en aquest projecte. Consensua el contingut d’enquestes i/o entrevistes que tindran lloc en diferents moments posteriors a la posada en productiu del producte del projecte
  8. Avaluació de beneficis i satisfacció: En aquest punt, i temps després del tancament oficial del projecte, l’equip avalua el resultat d’enquestes i entrevistes de satisfacció, amb el que actualitzarà l’arxiu de lliçons apreses, o aixecarà les alarmes o iniciatives que consideri útils en funció dels resultats Això pot incloure accions d’evolució o adaptació del producte del projecte, canvis sobre el govern del projecte, i/o canvis sobre les normes de qualitat

Reunió de planificació de cicle

La planificació (PLN) no és una acció única que es duu a terme a l’inici d’un projecte. Aquesta concepció de la planificació com acció única inicial és una forma ineficient d’afrontar el canvi inevitable en les organitzacions actuals.

Es necessita més agilitat en la planificació; i proporcionar un mètode de treball que faciliti una planificació dinàmica basada en cicles iteratius de construcció de valor per a l’organització. Però és important tenir clars i tancats l’abast i els objectius que persegueix el producte del projecte. El dinamisme en la planificació no pot significar incloure o treure arbitràriament aspectes funcionals, operatius o tecnològics considerats crítics.

Si plantegem la planificació com un element viu que apareix de forma iterativa com a fita en cada cicle del projecte, llavors ens veurem abocats a plantejar la construcció de tots els documents d’enginyeria necessaris per al projecte (disseny funcional, tècnic, desplegament, testing, etc.) també de forma iterativa i incremental. I fins i tot plantejarem les accions de posada en productiu i pla de formació de la mateixa manera. Això facilita enormement la tasca d’avaluació contínua i acceptació per part dels usuaris clau i les àrees usuàries a les quals va destinat el producte.

La planificació iterativa té una contrapartida important: Cal ser molt curós a l’hora de mantenir la coherència d’una planificació focalitzada en cicles, respecte al compromís global en l’acompliment d’un abast, uns objectius, un pressupost i un calendari global. Això requereix d’un esforç per a que l’equip mantingui constantment una visió global del projecte. Això és extensible a tots els elements documentals i d’enginyeria necessaris per a l’execució del projecte. Tots els elements que es construeixen incrementalment requereixen d’un esforç addicional per a mantenir la coherència global.

El document que articula la planificació és el document de Planificació (PLN), en què queden definits el calendari, la forma en què s’avalua la qualitat, la forma en què es comunicarà i s’organitzarà el projecte, i la relació de riscos i plans de mitigació

Reunió de seguiment

No s’ha d’entendre la reunió de seguiment com a l’òrgan de govern intern de projecte. L’equip de projecte no fa reunions de seguiment programades en calendari. Es coordina cada dia, i avalua els resultats interns, o tracta els problemes cada dia

La reunió de seguiment és una acció que està per sobre de l’operativa diària del projecte, i que té com a objectiu informar als òrgans de seguiment, sobre les accions realitzades fins a la data. Aquestes reunions poden estar planificades, o tenir lloc a demanda (quan apareix una fita clau, o un problema que no es pot resoldre a l’intern de l’equip)

El document que articula la reunió de seguiment és l’Informe de Seguiment (IFS). I es conforma com a acta de reunió on s’expressa la situació general del projecte, la situació dels riscos, i les principals decisions preses. Els informes de seguiment són coneguts per tot l’equip del projecte i determinen la seva priorització a alt nivell. L’equip és autoorganitzat, però no completament autònom. L’òrgan de seguiment té la potestat de marcar la priorització dels grans elements funcionals, però no la forma o l’ordre en què es realitzen les tasques en l’intern de l’equip, ja que hem de respectar la premissa que l’equip és autoorganitzat

Reunió de resultats i acceptació

La reunió de resultats és la peça que ens ajuda a determinar fins a quin punt som d’àgils en l’execució del projecte. Un projecte amb un nombre elevat de sessions de presentació de resultats i acceptació implica un flux de treball focalitzat en l’obtenció iterativa de producte de valor. És a dir, en la construcció iterativa i incremental del producte del projecte, que és explotat per l’usuari des del primer cicle.

La presentació de resultats i acceptació s’articula directament a través del producte creat, i de com aquest resol els objectius plantejats per al cicle en curs. Sense documents de presentació. Directament amb el producte. En la presentació de resultats també es cerca activament una acció pràctica d’acceptació per part dels usuaris clau. L’acceptació implica obligatòriament l’acceptació de l’increment de producte proporcionat, i l’inici del cicle següent.