La gestió de l'abast del projecte és potser el procés més crític de tota la gestió del projecte, com hem dit. És on es produeixen les desviacions més importants i, sovint, fracassos absoluts, en el contingut (què volia el client), el temps i els costos. I sens dubte en la satisfacció de clients i usuaris i, sovint, en la seva repercussió pública (la resposta dels accionistes, en l'empresa privada; penalitzacions o impacte negatiu en la premsa i l'opinió, en el sector institucional).

En l'etapa o grup de processos de planificació, la planificació de l'abast inclou tres processos:

1. La recollida de requisits, és a dir, la definició i documentació de les necessitats que, segons el parer dels interessats, permetran cobrir els objectius del projecte.
2. La definició detallada de l'abast, és a dir, la descripció detallada del projecte i del producte o productes (lliurables) que s'obtindran.
3. La definició de fites i la distribució de l'estructura del treball (EDT), és a dir, subdividir el conjunt del treball i els seus lliurables en parts o components menors.

5.3.1. Recollida de requisits

Ja es veu que hi ha molts tipus de requisits, de molts nivells i procedents de moltes fonts i parts interessades. No tots són iguals, ni tenen la mateixa importància per al projecte, ni són assumibles en l'abast, el pressupost i el calendari inicials acordats amb el client. És bàsic recordar això contínuament i fer-ho recordar al client/comprador.

Igual que els objectius, els requisits haurien de complir els principis anomenats SMARTT:

• Specific (específics, sense ambigüitats, ni descripcions difuses).
• Measurable (quantificables, tant com es pugui).
• Agreed (acordats amb els interessats i, en cas de conflicte, amb el comprador o director del projecte per part del client).
• Realistic (assolibles dins de les limitacions tècniques, d'abast, temps i calendari).
• Traceable (que sigui possible la traçabilitat o el seguiment i avaluació de l'assoliment, i que se'n pugui validar la consecució).
• Testable (això és especialment clau; que se'n pugui provar la consecució internament i per part de l'usuari en el moment de la operació).

Per a finalitzar, cada requisit hauria de ser complet (que no necessiti altres requisits posteriors) i consistent (que no sigui contradictori amb altres o estigui potencialment subjecte a canvis permanents). Aquests dos criteris valen per a cada criteri separadament i per a tots junts.

El procés de presa de requisits, segons el PMBOK, es representa en la figura 6.

Figura 6. Components del procés de presa de requisits segons el PMBOK

5.3.2. Definició detallada de l'abast

Normalment, ni el client ni l'empresa de serveis per a la qual treballem no ens admetrà un contracte subordinat a la presa de requisits de detall, ni internament donarà un mandat a un director de projecte amb aquests condicionants.

La realitat és així. Necessitem un pressupost inicial, un calendari inicial i un abast inicial per a començar a treballar. Però per a poder planificar el projecte, necessitem una definició de requisits molt més precisa.

Una altra diferència és que, en el nivell de definició inicial, normalment treballem en l'àmbit de projecte, i no necessàriament hem fet una selecció o aprovació definitiva d'un producte o d'una manera de produir-lo. En el nivell de la definició detallada pròpia de la planificació, ja estem en el nivell dels productes, quin producte es construirà o implantarà i com es construirà.

La definició detallada de l'abast, per tant, és un producte no gaire diferent de la definició inicial, però més refinat, precís i detallat i que incorpora una descripció del producte o dels productes.

El procés de definició detallada de l'abast, tal com es presenta en el PMBOK, es mostra en la figura 7.

Figura 7. Components del procés de definició detallada de l'abast

La definició detallada de l'abast inclou els productes següents:

• Descripció actualitzada del producte, servei o resultat i, freqüentment com a annex, la documentació de requisits.
• Criteris d'acceptació dels productes.
• Lliurables del projecte, tant si són productes com serveis, components del projecte o material complementari (per exemple, documentació).
• Exclusions del projecte. Per diferents raons, molts directors de projecte o companyies de servei no s'atreveixen a incloure aquest apartat, que és extremament crític. És una descripció argumentada del que no es farà i per què, que ajuda d'una manera extraordinària a gestionar les expectatives de clients i interessats.
• Limitacions i assumpcions. Són les condicions organitzatives, de calendari o de pressupost, sota les quals es durà a terme el projecte i, si escau, les condicions per a modificar-lo. Actualment, molts projectes es fan sota pressupostos tancats, però s'estableixen condicions sota les quals el pressupost es pot revisar. O, al contrari, es fan "per administració" (hores esmerçades), però s'estableixen uns productes mínims que s'han d'obtenir i unes condicions per a substituir-los.
• Fites. Són els estadis o les condicions intermèdies pels quals ha de passar el projecte per a assolir els objectius finals. Sovint, però no sempre, estan  vinculades a la descomposició del projecte en parts menors (EDT o WBS), a la qual ens referirem a continuació.
• Les responsabilitats per les fites. És l'assignació de rols i responsabilitats en el nivell de fites, és a dir, identificar qui és responsable de la consecució de cada fita i quins altres membres de l'equip o parts interessades del client participen i amb quin rol o nivell de responsabilitat.

El document Definició detallada de l'abast és un dels que hem considerat bàsics per a la gestió de projecte.

a) El pla de fites

El concepte de fita no existeix en el PMBOK ni en altres metodologies i procedeix de l'enfocament goal directed project management (GDPM). Tampoc en aquest nivell no s'acostumen a establir les responsabilitats. Segons la nostra opinió, fer-ho aquí facilita la relació i el diàleg entre la part de negoci (i en particular el patrocinador del projecte) i l'equip de projecte (que sol tenir un gran pes tècnic), d'una manera senzilla, visual i comprensible, abans d'entrar en tecnicismes, detalls i complicades eines de gestió. També permet visualitzar tots els components "aliens" al projecte en sentit estricte (els de gestió del canvi, que es diu ara), sobre els quals el client ha d'actuar per a assegurar l'èxit del treball. Finalment, establir fites, si es lliga als criteris de comprovació de lliurables, no planteja cap dubte: les coses hi són o no hi són, s'han fet o no s'han fet.

Els objectius finals d'un projecte guien la definició dels seus estats intermedis, les fites. Per a ser efectives, les fites han de tenir les característiques següents:

• Han de reflectir el què i no el com.
• Han de ser fàcils de llegir i d'entendre per a la direcció.
• Han de ser punts de decisió.
• Han de ser concretes i mesurables.
• Han de ser rellevants i limitades en nombre.
• Han d'ocórrer en períodes de temps manejables.
• S'han d'assenyalar les dependències amb altres fites.

Una regla senzilla és escriure les fites de manera que reflecteixin l'estat que es vol assolir i les condicions per a verificar que s'han assolit. Se'n poden veure alguns exemples aquí:

Exemples de formulació de fites

• Quan s'ha presentat el pla detallat de treball.
• Quan l'entorn de desenvolupament està disponible.
• Quan s'han fet les proves d'usuari.
• Quan s'ha preparat el pla de formació.
• Quan s'ha pujat el sistema a producció.
• Quan s'ha aprovat el nou procés de treball.
• Quan s'ha comunicat el nou servei.
• Quan s'han habilitat les instal·lacions.

Aquestes fites es poden representar de manera gràfica mitjançant la utilització d'eines de suport que es mencionaran al tauler de l’aula, en què les fites principals del projecte apareixen representades en forma de rombes.

Figura 8. Exemple de planificació d'un projecte

b) Matriu de rols i responsabilitats

La definició de fites en el projecte ha d'anar acompanyada de la definició de rols i responsabilitats per a cada una de les fites. La definició de rols i responsabilitats implica designar per a cada fita:

• Qui és el responsable de l'execució de cada fita.
• Qui pren les decisions, sol o juntament amb altres.
• Qui gestiona els recursos i controla el progrés del treball.
• Qui n'ha de ser informat.
• Qui ha de ser consultat.
• Qui hi ha de participar.
• Qui ha de donar suport a l'equip o dotar-lo d'infraestructura.
• Qui assegura la qualitat dels resultats.

En el nivell de fites és molt important establir les responsabilitats del nivell directiu i del personal del client, no solament les de l'equip de treball o, si escau, els subcontractistes.

6.3.3. Estructura de descomposició del treball (EDT)

Per exemple, en un projecte de construcció i implantació de programari a mida (seguint la metodologia típica de desenvolupament estructurat al llarg del cicle de vida, system development life cycle), podríem hipotèticament descompondre el total en els paquets següents:

• La gestió del projecte.
• La presa de requisits.
• El disseny de detall.
• La construcció.
• La integració.
• Les proves.
• La implantació.

Si el projecte és prou gran, podríem continuar descomponent cada paquet en altres de més petits, per exemple, el disseny podria incloure

• Planificació del disseny.
• Disseny lògic.
• Disseny físic.
• Especificacions de seguretat.
• Especificacions d'interfície amb altres programes.
• Especificacions de conversió de dades.
• Revisions d'usuari.
• Revisions de personal tècnic.
• Revisions de documentació.

Els únics consells que val la pena donar són dos de força pràctics:

1) No deixar la descomposició tan amunt que el projecte es converteixi en immanejable, i sigui impossible d'assignar recursos, costos i responsabilitats; no baixar tan avall que el cost del control es converteixi en insuportable. 2) Vincular tant com es pugui les EDT als productes i les fites. Això fa més fàcil la comprensió i el diàleg amb el client i amb l'equip, i l'orientació dels uns i els altres al resultat. Molts productes intermedis o activitats auxiliars de tipus tècnic no interessen a ningú al final del dia.