5.2.02TS Tecniche di Definizione dell'Ambito

Contenuto (Scope) è il termine utilizzato per descrivere il perimetro del progetto. Il contenuto viene utilizzato per definire ciò che il progetto realizzerà e ciò che non realizzerà. Per grandi progetti, può comprendere le organizzazioni interessate, le transazioni impattate, i tipi di dati utilizzati, etc.

Se osservi i motivi per cui falliscono molti progetti, di solito scopri che è dovuto a due problemi. O il team di progetto non ha impiegato abbastanza tempo a definire il lavoro, e/o c’è stata carenza nella gestione del contenuto. Anche se il project manager ha fatto un buon lavoro nel definire il contenuto, la parte difficile arriva con il dover gestire il progetto nei termini del contenuto concordato.

Lo scopo della gestione del contenuto è proteggere l’applicabilità di Capitolato di Progetto e requisiti di progetto approvati. In altri termini, il Capitolato di Progetto definisce il contenuto complessivo del progetto, ed i requisiti di business definiscono le deliverable in dettaglio. Il team di progetto si è impegnato per una scadenza e per un budget su queste definizioni di alto livello e di dettaglio. Se le deliverable cambiano durante il progetto (e di solito questo significa che il cliente vuole più funzioni), le stime di costo, impegno e durata possono non essere più valide. Se lo sponsor accetta di inserire il nuovo lavoro nel contenuto del progetto, il project manager ha il diritto di aspettarsi che vengano modificati budget e scadenza  (di solito in  aumento)  per rispecchiare il lavoro aggiuntivo. Questa nuova stima di costo, impegno e durata diverranno il nuovo target approvato.

A volte il project manager crede che gestire il  contenuto significhi dire "no" al cliente. Ciò rende il  project manager nervoso e preoccupato. 

Invece, la buona notizia è  che gestire il contenuto significa  permettere allo Sponsor di prendere le giuste decisioni che modificheranno il contenuto del progetto.  

Questo è troppo importante. Pochi clienti possono vedere ed raccontare tutti i requisiti fin dall'inizio  di un progetto. Perciò, solitamente, ci sono modifiche che devono essere introdotte durante il ciclo di vita del progetto. Queste modifiche possono essere molto necessarie  per la soluzione e ci possono essere valide ragioni di business per cui dovranno essere apportate. Il  project manager e il suo  team devono riconoscere quando queste modifiche sono necessarie. Però, devono seguire un predefinito processo di modifica al contenuto. Questo processo, infine, fornisce le appropriate informazioni allo Sponsor e gli consente di decidere se le modifiche dovranno essere approvate, sulla base del valore di business e l'impatto sul progetto in termini di costi e schedulazione.

Quante volte hai sentito parlare o sei stato coinvolto in un progetto che è fallito miseramente? O forse, semplicemente non è stato di successo quanto doveva esserlo? Ti sei mai guardato indietro per capire cosa ha fatto andar male  quel progetto? Se lo hai fatto, molto probabilmente avrai anche detto

"Lo so, avremmo dovuto pianificare di più!".

Molti progetti hanno scadenze, che sembrano diventare sempre più vicine. Fissando date di  scadenze aggressive  si genera pressione sul  project manager in modo che egli avvii il progetto il prima possibile. Tuttavia, prima di iniziare il progetto, occorre impiegare preventivamente del tempo  per pianificare, in modo da essere sicuri che il lavoro è stato  ben compreso, ed accettato.

Questo non è tempo sprecato,  è il tempo che il project manager impiega per assicurarsi che il team di progetto ed il cliente abbiano la stessa percezione di cosa dovrà produrre il progetto, quando sarà ultimato, quanto costerà, chi eseguirà il lavoro e come il lavoro sarà svolto.

Alla fine di un progetto difficile, i benefici della pianificazione potrebbero essere ovvi; ma essi sono noti fin dall'inizio. A livello alto i benefici della pianificazione includono:

Comprendere ed accettare gli obiettivi di progetto, le consegne previste,  il contenuto, i rischi, i costi, l'approccio, etc. (dal Capitolato di Progetto).

Determinare se il business case originale è ancora valido. Quando il progetto è stato approvato inizialmente, il costo e la durata sono stati stimati ad un livello alto, forse fino a +-50%. Adesso che il progetto parte, le stime dovrebbero essere riviste per approssimarle a +- 10%. Questo ulteriore affinamento può comportare che le stime risultino superiori a quelle precedenti, e questi numeri più alti potrebbero rendere il business case meno attraente. Per esempio, dal punto di vista del business, un progetto potrebbe avere senso se richiede 10.000 ore. Se dal  processo di  pianificazione di dettaglio più affinato, risultasse che la stima più accurata è di  20.000 ore, il progetto potrebbe non avere più senso dal punto di vista del business.

Garantire che le risorse necessarie saranno disponibili quando serviranno. Questo è il risultato della comprensione del progetto  da parte dell’organizzazione e della creazione della schedulazione con risorse assegnate.

Fornire una base di partenza di alto livello con la quale verificare gli avanzamenti  successivi. Questo è il risultato della creazione della tempificazione delle milestone sulla base della schedulazione più dettagliata.

Convalidare i processi da utilizzare per gestire il progetto con il cliente fin dall'inizio. Le procedure utilizzate per gestire il progetto dovrebbero essere discusse e spiegate al cliente ed al team di progetto.

I piccoli progetti necessitino di un ciclo di pianificazione più breve. L'impegno richiesto per pianificare il progetto dipende dalla quantità di informazioni, e dal livello di dettaglio che occorre per essere compreso e documentato. La durata richiesta per definire il lavoro dipende dal tempo necessario per scoprire e documentare le informazioni ed il tempo necessario per ottenere l'accettazione e l'approvazione del cliente.

Per piccoli progetti, l'organizzazione è molto semplice - forse ci sono solo  project manager e Sponsor del cliente. La persona che sta gestendo il progetto può essere anche la sola persona che lavorerà sul progetto.

Invece, per i grandi progetti,  è necessaria una struttura organizzativa elaborata e formale. Puoi aver membri del gruppo di  progetto, uno Sponsor di Direzione, uno Sponsor di progetto, un manager dell'utente, un direttore di progetto, un comitato esecutivo, fornitori, clienti e altri  soggetti interessati. Non bisogna diventare eccessivamente complessi, ma più gente è coinvolta nel progetto, più  è importante che ognuno abbia chiaro il proprio ruolo e le proprie responsabilità. Per esempio, l'ultima cosa che un project manager desidera è  avere persone che  danno disposizioni come se fossero lo Sponsor, quando realmente essi sono solo manager delle parti interessate. 

Un aspetto del  Capitolato di Progetto è definire la struttura organizzativa ed  i ruoli e le responsabilità di tutti i principali partecipanti. Di solito, i tipici ruoli e responsabilità possono essere definiti in anticipo per l'organizzazione, e poi riusati in modo appropriato da progetto a progetto. Molti ruoli e responsabilità comuni ai progetti sono descritti nella sezione 1.2.2 Definizione del Lavoro / Ruoli e responsabilità.

Alla fine del processo di  Definizione e Pianificazione (passo 1 e passo 2) dovresti aver raggiunto un accordo con lo Sponsor sul lavoro da fare,  il costo (tempo) e la durata necessaria per ultimare il lavoro. Questi tre elementi formano un concetto chiamato "triple constraint". L'aspetto chiave del triple constraint è che se cambia uno dei tre elementi, deve cambiare anche almeno uno degli altri due, se non entrambi. (Il triple constraint viene illustrato in più modi analoghi. Il costo può essere anche sostituito dall'impegno, che ha più senso se i costi del lavoro sono tutti interni, e se non ci sono altri costi. A volte, il contenuto viene indicato come qualità, che pone l'attenzione sul rilascio di un certo livello di qualità ad un certo costo ed entro un certo tempo. Questo è l'aspetto più debole del triple constraint, ma i concetti generali sono sempre validi.)

Il Capitolato di Progetto descrive il progetto ad un livello alto. Il Capitolato di Progetto descrive specificatamente i bisogni del cliente, come pure le stime dell'impegno del team di progetto, la durata ed il costo per soddisfare questi bisogni. I dettagli delle necessità del cliente vengono poi definiti più in dettaglio attraverso la raccolta dei requisiti di business.

E' importante per il project manager ed il team di progetto comprendere che i bisogni reali del cliente possono o non possono essere gli stessi che ti sono stati espressi e che sono alla base del Capitolato di Progetto e  dei requisiti. In molti casi, il cliente non ha chiaro i suoi reali bisogni alla partenza del progetto. Le esigenze reali a volte possono evolvere nel corso del progetto. Similmente, il cliente può avere una chiara visione dei suoi bisogni, ma può avere difficoltà a rappresentarli al team di progetto. In un certo senso, questo è lo scopo  della gestione delle modifiche al contenuto - permettere al cliente di cambiare i requisiti del progetto in corso d'opera.

Il team di progetto non può fare altro che documentare i bisogni manifestati dal cliente ed utilizzarli come base per l'approvazione del Capitolato di Progetto e dei Requisiti di Business. Però, è anche vero che il team di progetto dovrebbe cercare di coprire i bisogni reali del cliente. Ciò richiede tecniche come fare domande appropriate, fare domande in successione logica, raccogliere input dai principali stakeholder, fare ulteriori domande quando i requisiti sembrano illogici, etc. Ovviamente, il team di progetto dovrebbe fare tutto il possibile per cercare di coprire i bisogni reali del cliente. Più i bisogni reali sono prossimi a quelli espressi dal cliente e più possibilità ci sono di realizzare un progetto corretto fin dalla prima volta.

Non sembra che, molti dei problemi che si incontrano su un progetto tendono ad emergere verso la fine del processo di codifica o di test? Infatti, alcuni project manager  volutamente si affrettano nei processi  di pianificazione, analisi e disegno, perché pensano di  eliminare gli errori durante il  processo di test. Sfortunatamente, più tardi si scoprono gli errori e più tempo e denaro occorrono per correggerli. Quando sviluppi la tua schedulazione, cerca di investire più tempo nel lavoro  di  preparazione iniziale e  nella pianificazione. Ciò, alla fine, ti farà risparmiare tempo e denaro sull'intero progetto. Per esempio, impiegando più tempo nella pianificazione iniziale, si risparmia tempo nell'analisi. Investendo più tempo nell'analisi,  il lavoro di disegno  procede più agevolmente. Investendo più tempo nella revisione delle deliverable verranno scoperti gli errori prima, risparmiando tempo in fase di test. Effettuando i test accuratamente si risparmia tempo nella fase di implementazione e di supporto. Naturalmente, non bisogna esagerare con pianificazione e analisi, non darebbe niente di più. Ma bisogna cercare di essere diligenti in questo lavoro iniziale, senza avere  fretta. Il tempo investito inizialmente, gioverà più di quanto si può credere all'intero progetto.

Il processo di creare il Capitolato di Progetto, la Schedulazione ed il Budget  può richiedere molto tempo e può essere molto complicato. Comunque, il lavoro non deve essere lasciato disorganizzato, per la stessa ragione per cui sviluppi la schedulazione per iniziare un grande progetto. Appena assegnato, il  project manager dovrebbe creare una schedulazione  a breve termine per pianificare e seguire le attività iniziali. Questa schedulazione iniziale dovrebbe coprire il tempo necessario a creare il Capitolato di Progetto e la schedulazione completa. Se questo è un processo di due settimane, il project manager dovrebbe creare un piano ad interim di almeno due settimane - forse tre. Se il tempo per creare la Capitolato di Progetto finale e la schedulazione è quattro settimane, la schedulazione iniziale dovrebbe coprire almeno quattro settimane, se non cinque o sei.  Questa schedulazione preliminare copre tutta l'organizzazione e la pianificazione delle attività immediata  fino a che non è pronta la schedulazione di progetto formale che governerà il resto del progetto. Questa schedulazione iniziale dovrebbe essere definita ad un livello organizzativo in modo che tutti i progetti utilizzino lo stesso processo per definire e pianificare il lavoro.

Le seguenti informazioni possono essere utili:

• Le  deliverable che fanno parte del contenuto e quelle escluse dal  contenuto.  In definitiva, bisogna includere nella descrizione del contenuto, soltanto le deliverable finali e le deliverable che interessano al cliente. Devono essere elencate tutte le deliverable. In più, devono essere elencati come deliverable di progetto il report sui requisiti di Business e lo Stato di Avanzamento, perché sono deliverable che il cliente deve approvare. Non c’è bisogno di citare documenti interni al progetto come la schedulazione di progetto, il disegno tecnico o i casi prova.  Lo sponsor non comprenderebbe queste deliverable e non desidera vederle mai. (Anche se qualche cliente le vuole vedere).

• I principali processi del ciclo di vita compresi nel contenuto  e quelli che non sono compresi. Ad esempio, il tuo progetto può comprendere solo la fase di Analisi e non le fasi di  disegno, codifica  e test.

• I tipi di dati compresi nel contenuto di progetto  e quelli non compresi.  I “Tipi di dati” si riferiscono a categorie di deliverable come  dati finanziari, dati di vendita, dati del personale. E' possibile che il tuo progetto lavori con certi tipi di dati e non ha bisogno di altri.

• Le fonti dei dati (o  database) che fanno parte del contenuto o  che non ne fanno parte. Questo è simile al tipo di dati, eccetto che qui fai riferimento a dati aggregati, come Anagrafiche Clienti, Contabilità Generale, Fatturazione / Sistema di fatturazione, etc. (Queste fonti di dati possono avere più di un tipo di dati).

• I reparti  coinvolti e quelli che non sono coinvolti.  In alcuni casi, i reparti coinvolti nel progetto aiutano a definire il perimetro del progetto. Per esempio, il tuo progetto può riguardare le Risorse Umane e la Contabilità, mentre  la Produzione potrebbe essere fuori dal contenuto del progetto.

• Le principali funzionalità che fanno parte del contenuto e quelle escluse. Per esempio, il supporto decisionale e la gestione del reporting  potrebbero far parte del contenuto, mentre le elaborazioni notturne potrebbero essere fuori dal contenuto.

I propositi (goal) sono dichiarazioni di alto livello che forniscono il contesto completo di ciò che il progetto cerca di realizzare.

Gli obiettivi sono dichiarazioni di livello più basso che descrivono gli specifici, tangibili prodotti e deliverable  che il progetto produrrà.

La definizione di Propositi e Obiettivi è più  un'arte  che una scienza, ed è difficile definirli ed allinearli correttamente. Però, con la pratica e l’utilizzo di alcune definizioni comuni, tu puoi iniziare ad identificare e specificare le differenze tra propositi ed obiettivi.

Poiché il proposito è ad un livello alto, può richiedere più di un progetto per raggiungerlo. Nell'ipotesi precedente, per esempio, ci può essere una componente tecnologica per aumentare la soddisfazione dei clienti. Ci possono essere nuove procedure, nuovi corsi di formazione, riorganizzazione del servizio di help desk e modifiche al sistema salariale. Possono essere necessari diversi progetti su un lungo periodo per realizzare il proposito manifestato.

Il proposito dovrebbe far riferimento ai benefici di  business in termini di costo, velocità e/o qualità. Nel precedente esempio, l'attenzione è sulla qualità del servizio. Anche se il progetto non è direttamente a supporto del  business, ci dovrebbe essere un legame indiretto. Per esempio, un progetto di infrastruttura IT  per installare un nuovo server, in ultima analisi,  può fornire migliori tempi di risposta ai clienti, migliori prezzi / prestazioni, o altri benefici di  business. Se non c'è nessun valore di  business, il progetto non dovrebbe essere avviato.

Se riesci a misurare il raggiungimento di un proposito, probabilmente è ad un livello troppo basso ed è poco più di un obiettivo. Se un proposito non è raggiungibile attraverso una combinazione di progetti, forse è  stato scritto ad un livello troppo alto.

Nell'esempio precedente, si dovrebbero concepire uno o più progetti che alla fine dovrebbero aumentare la soddisfazione del cliente. La dichiarazione di intenti di raggiungere la piena soddisfazione del cliente non è possibile con una combinazione di progetti. Può essere invece la visione, che, ad un livello più alto, indica la direzione e l'aspirazione, ma che non può mai essere realizzata.

E' importante comprendere business e dichiarazioni di propositi, anche se, secondo la metodologia TenStep, i propositi non fanno parte del Capitolato di Progetto. I propositi sono più importanti dal punto di vista del  business. Il  project manager deve comprendere i propositi di  business ai quali il progetto cerca di contribuire. In realtà, non ci sono propositi di progetto, ma solo obiettivi di progetto.

Gli obiettivi sono dichiarazioni concrete che descrivono cosa il progetto cerca di produrre. Un obiettivo andrebbe  scritto ad un livello più basso di un goal, in modo che possa  essere valutato alla conclusione del progetto per vedere se è stato raggiunto. Le dichiarazioni di intenti sono vaghe. Un obiettivo ben formulato sarà  Specifico, Misurabile,  Realizzabile, Realistico e  Fissato nel tempo (SMART). (SMART è un modo per qualificare un obiettivo, ma un obiettivo non deve assolutamente essere SMART per essere valido).

Un esempio di obiettivo potrebbe essere "potenziare il centralino telefonico dell' help desk per il 31/12,  per ridurre il tempo di attesa dei clienti entro i due minuti ". 

L'obiettivo è molto più concreto e  specifico rispetto al proposito generale.

L'obiettivo è  misurabile in termini di  tempi medi di attesa che il nuovo centralino cerca di ottenere.

Si può assumere che l'obiettivo è  raggiungibile e realistico.

L'obiettivo ha una scadenza e deve essere completato per il 31 Dicembre.

Gli obiettivi devono far riferimento alle deliverable di progetto. Nell’esempio precedente, l'obiettivo si riferisce al potenziamento del centralino telefonico. Se non si può determinare cosa bisogna produrre per raggiungere l'obiettivo, forse l'obiettivo è formulato ad un livello  troppo alto. Al contrario, se un obiettivo descrive le caratteristiche delle deliverable, è scritto ad un livello troppo basso. Se, invece, la dichiarazione  descrive i componenti e le funzioni, è un requisito e non un obiettivo.

Se il progetto fa parte di un grande programma, gli obiettivi di tutti i  sottostanti progetti dovrebbero essere allineati con gli obiettivi del programma.

Gli obiettivi sono importanti perché mostrano il consenso tra il project manager e lo Sponsor del progetto sul contenuto globale  del progetto. oggettive deliverable specifiche per un progetti IT, per esempio, possono  o non possono avere senso per lo Sponsor di progetto. Comunque, gli obiettivi devono essere scritti in modo che siano comprensibili da tutti gli interessati.

Gli obiettivi di progetto, ed i propositi di  business che essi supportano, devono essere definiti e concordati prima che il progetto abbia inizio. Le deliverable vengono create sulla base degli obiettivi.

Tuttavia, su molti progetti, è più facile vedere le deliverable che bisogna sviluppare, anziché gli obiettivi che guidano le deliverable.

Se credi di conoscere le deliverable che bisogna realizzare, lavora con lo Sponsor sul perché esse devono essere realizzate. Le risposte a questa domanda aiuta a scoprire gli obiettivi del progetto. Dopo, potrai essere sicuro che tutti gli obiettivi sono allineati ai propositi di business.

Se pensi che devi realizzare certe deliverable, ma non sei in grado di collegarle agli obiettivi di progetto ed ai propositi di business, ti devi chiedere seriamente perché le stai realizzando.

Una semplice riunione con  i maggiori stakeholder interessati è un buon modo per stabilire gli obiettivi e ottenere il consenso allo stesso tempo. 

Quando il progetto è stato proposto per il finanziamento, sarà stato definito un insieme di obiettivi di alto livello e di deliverable. Ci possono anche essere alcune  dichiarazioni di contenuti di alto livello. Tutte le informazioni raccolte all’inizio dovrebbero essere utilizzate come punto di partenza per definire più in dettaglio il contenuto nel Capitolato di Progetto. Se trovi che non hai sufficienti informazioni per creare una chiara e comprensiva descrizione del  contenuto, devi lavorare con lo Sponsor per raccogliere informazioni aggiuntive. Questo è il principale scopo del processo di definizione e pianificazione.

Se hai obiettivi di progetto, analizzali per strutturare la definizione del contenuto. Per definizione, ci devono essere una o più deliverable da creare per soddisfare ogni obiettivo, e definire le deliverable di progetto è uno degli aspetti primari del contenuto di progetto. Dopo aver determinato le principali  deliverable che produrrà il progetto, inizia a fare altre domande per determinare altri aspetti del contenuto. Le  deliverable descrivono 'cosa' rilascerà il progetto. Tu puoi identificare anche  'quali' organizzazioni sono impattate, 'che' tipi di dati sono necessari,  'quali' dispositivi e funzioni sono necessari,  etc.

Come segno di chiarezza e di contrasto, tu puoi identificare anche le condizioni di ciò che è fuori dal contenuto, descrivendo quali deliverable non saranno create, quali organizzazioni non saranno coinvolte, quali dispositivi e funzioni non sono inclusi,  etc. Naturalmente, c'è un numero infinito di cose fuori dal contenuto del progetto. Ai fini della Definizione del Contenuto, bisogna includere solo quelle dichiarazioni che aiutano a definire il perimetro del progetto, e  confinano con le aree correlate sulle quali il lettore potrebbe avere dei dubbi. Per esempio, se stai installando un software finanziario, puoi affermare che un nuovo pacchetto di Contabilità Pagamenti è incluso nel progetto, mentre il Sistema Acquisti  è escluso dal contenuto del progetto. Ciò ha senso perché i processi di  Acquisti  e Pagamenti  sono correlati e si potrebbe discutere sul fatto che gli acquisti facciano parte del contenuto del progetto. Comunque, non è il caso di elencare tutti gli altri processi fuori dal contenuto.

E' buona regola documentare i reparti che contribuiscono al contenuto  e quelli che non sono affatto coinvolti. Così, il lettore potrà determinare più facilmente se deve aspettarsi di essere impattato  o deve soltanto assistere alla realizzazione del  progetto. Inoltre, può avere anche senso identificare quali reparti sono coinvolti nella realizzazione  in modo da ottenere le risorse per creare il team di progetto - o -  un Comitato Esecutivo.

Quando avrai finito di definire obiettivi e contenuto, torna indietro e verifica se sono allineati. Non puoi avere nessun obiettivo che fa riferimento a deliverable che non sono state definite nel contenuto. Se non stai sviluppando qualcosa per soddisfare un obiettivo, non sarai in grado di raggiungere quell’obiettivo.

Analogamente, non devi prevedere deliverable nel tuo progetto che non mirano a raggiungere obiettivi del progetto.  Se stai proponendo di sviluppare deliverable che non tendono a raggiungere obiettivi di progetto, ti devi chiedere perché. Poiché gli obiettivi descrivono lo scopo del progetto, perché dovresti sviluppare deliverable che non mirano a soddisfare quegli obiettivi?

Se gli obiettivi e le deliverable nella sezione del contenuto non sono allineati, devi trovare come allinearli.

Se hai un obiettivo senza una deliverable, tu devi verificare se l’obiettivo è veramente importante. Se lo è, allora tu devi aggiungere o modificare le deliverable per raggiungere questo obiettivo.

Se hai una  deliverable senza un obiettivo, allora ti devi chiedere se la deliverable è veramente importante. Se non lo è, allora eliminala dal progetto. Se la deliverable è veramente importante, devi lavorare con lo sponsor per determinare l’obiettivo di business per crearla. E’ come se l’obiettivo fosse valido, ma non se ne è ancora parlato.

L'approccio al progetto è la sezione della Definizione di Progetto che descrive in parole lo spirito impiegato per la creazione del Piano di Lavoro del progetto. Ci sono due vantaggi nel creare la sezione Approccio. Primo, queste informazioni sono a beneficio  degli utenti e delle parti interessate che non sono in grado di interpretare facilmente il piano di lavoro. Ci sono diversi modi in cui può essere preparata questa sezione. Di solito, si parte dal contenuto generale su come l'organizzazione e l'ambiente saranno impattati dal progetto. Poi si affronta il progetto cronologicamente, dall'inizio alla fine.

Naturalmente, non occorre descrivere i dettagli a livello di attività. Ci si deve fermare a livello di milestone, stadi o fasi.

L'altro beneficio dell'approccio per progetto è che permette al  project manager ed al team di progetto di preparare un piano di lavoro di alto livello per il progetto e utilizzarlo poi per sviluppare il piano di lavoro di dettaglio. A volte il team di progetto trova difficile sviluppare un piano logico per realizzare il lavoro. Creando prima  un piano di livello alto può essere più facile suddividere il piano di lavoro in livelli più bassi.

A volte è difficile partire con questa sezione. Le seguenti informazioni vi danno più dettagli ed esempi sulle aree che possono essere descritte. E' da notare che molte di queste informazioni possono essere disponibili in altri posti, ma è nella sezione approccio che si lega ogni cosa nel contesto per il beneficio del lettore.

Discuti se alcune iniziative o strategie più importanti per la  compagnia impattano la struttura di questo progetto.

Identifica vincoli o date limite in termini di budget, impegno, tempi o qualità, e l'impatto sul progetto.

Descrivi tutti gli  standard della compagnia che impatteranno l'esecuzione del progetto.

Annota tutte le best practice della compagnia e del settore di industria che avranno effetto sul progetto.

Descrivi altre opzioni per l'approccio globale, e per quale motivo  ne  scegli  una rispetto ad altre. Annota perchè ritieni che questo approccio ha le maggiori  possibilità di successo rispetto ad altri.

Parla di come saranno supportate  e manutenute le  deliverable, una volta concluso il  progetto. Indica anche se l'approccio è stato influenzato dalle implicazioni di supporto e manutenzione.

Discuti qualsiasi altro progetto correlato che è  stato terminato, ancora in corso  o sospeso, che ha influenzato l'approccio di questo progetto e perchè.

Discuti, a livello alto, come il progetto procederà dall'inizio alla fine, e le interdipendenze tra le fasi e gli stadi  di livello alto.

Discuti tutte le tecniche che possono essere di interesse per il lettore. Per esempio, puoi  annotarlo nell'approccio, se i requisiti saranno raccolti in una sessione congiunta di sviluppo applicazioni (JAD).

Annota se saranno utilizzati nuovi processi o nuova tecnologia, e perchè.

Identifica qualsiasi esigenza insolita  di personale, come consulenti o specialisti esterni, e spiega perchè servono.

Descrivi l'utilizzo di fornitori esterni (outsourcer, fornitori o venditori), specialmente se devono svolgere lavoro significativo.

Naturalmente, queste sono idee per la sezione relativa all'approccio. Non devi necessariamente commentar tutti questi fattori;  molti possono non servire al tuo progetto. Lo scopo dell'approccio è  descrivere questi fattori e l'impatto che hanno sul Piano di Lavoro del progetto.  Questa sezione generalmente  è a beneficio del lettore - chi scrive conosce già queste informazioni. C'è la tendenza a scrivere questa sezione brevemente e velocemente, di conseguenza fornendo poco valore per il lettore. Se chi scrive è diligente e fornisce un buon contesto, questa sezione può invece essere di grande utilità per il lettore.

Gli stakeholder sono persone specifiche o gruppi di persone che hanno una parte o sono interessati nel risultato del progetto. Normalmente gli stakeholder appartengono all’azienda e possono essere utenti interni, management, impiegati, amministratori, etc. Un progetto può avere anche stakeholder esterni, compreso fornitori, associazioni di consumatori e organizzazioni governative.

Oltre a gestire le aspettative dello sponsor di progetto, il manager del project manager, il team di progetto e gli utenti, i piccoli progetti non si devono preoccupare molto di comprendere e gestire la comunità degli stakeholder nella sua interezza.

Però, man mano che il progetto diventa più grande, generalmente ci sono sempre più  stakeholder. Se hai una grande comunità di stakeholder occorre eseguire un’analisi di questi stakeholder. In alcuni casi, potresti aver bisogno del loro aiuto, e in altri casi bisogna informarli del contenuto del tuo progetto. L’analisi degli stakeholder aiuterà a determinare i vari gruppi di stakeholder e qual è il loro ruolo nel tuo progetto.

Per l’analisi degli stakeholder, utilizza il seguente processo:

5.2.02TS Tecniche di di Definizione dell'Ambito

Creare la WBS