Per progetti più grandi, consiglio di creare una matrice di tracciabilità dei requisiti. Ulteriori informazioni qui:

Matrice di tracciabilità dei requisiti nella gestione dei progetti (esempio + modello)

Processo n. 2: come reprimere i requisiti e definire l’ambito

Ecco un requisito :

“Il sito web pmbasics101.com dovrebbe avere la capacità di raccogliere email e inviare in cambio un documento PDF.”

Cosa serve per soddisfare questo requisito?

1. Seleziona un fornitore di servizi di posta.
2. Crea un account.
3. Progetta il modulo per raccogliere le email.
4. Implementa il modulo progettato.
5. Installa il plug-in dal fornitore del servizio di posta.
6. Carica il documento PDF.
7. Attiva il modulo.
8. Prova il modulo.

È solo un elenco di azioni richieste. Se lo inserissi correttamente come Deliverable e Work Package, finirebbe in:

1. Email Opt -in modulo
   1.1 Rapporto sui fornitori di servizi di posta
   1.2 Design del modulo approvato
   1.3 Modulo di iscrizione nell’ambiente di test
   1.4 Rapporto di prova

Quindi, come faccio si arriva dal requisito di una sola frase all’effettivo ambito di lavoro?

A) È possibile trovare qualcuno che abbia esperienza o conoscenza pertinente

Può essere stakeholder, clienti o consulenti, esperti in materia o altre parti.

Quindi, il tuo obiettivo è acquisirli dal team di progetto o semplicemente metterti in contatto per comunicare. Potrebbero avere già una soluzione.

In caso contrario, potresti ricevere indicazioni o consigli. È una tecnica di base che applicherai ampiamente.

B) Esegui l’analisi del prodotto

È applicabile quando devi creare un prodotto piuttosto che un servizio o un risultato.

Questa tecnica si concentra sulla scomposizione del valore del prodotto. Proprio come WBS fa con lo scopo.

Inoltre, è necessario analizzare il prodotto da punti di vista ergonomici e funzionali; e quindi prendere decisioni su materiali o processi conformi ai requisiti di prestazione.

25 Esempi di analisi del prodotto

Tutto sommato, il tuo obiettivo è definire risultati tangibili.

C) Usa la tecnica di generazione di alternative

Questa tecnica funziona bene quando hai esperienza nella natura del progetto.

Quindi, devi trovare la soluzione migliore per soddisfare i requisiti. Nella maggior parte dei casi, utilizzerai il brainstorming per ottenere le alternative.

Qual è l’obiettivo?

Devi definire chiaramente cosa fa e cosa non fa parte dell’ambito del progetto.

Processo n. 3: gestione dell’ambito del progetto con un software PM

Di sicuro, puoi monitorare l’ambito del progetto in qualsiasi app disponibile. Ad esempio, Google Drive, Evernote o MS Word andranno bene.

Tuttavia, ci sono seri vantaggi nell’usare un software di gestione dei progetti integrato per tenere tutto in un unico posto.

Idealmente, tu devono essere in grado di collegare i requisiti ai deliverable del progetto.

Quindi, dal deliverable alle attività specifiche con stime, rischi correlati e difetti.

Ad esempio, posso consigliare Paymo. È una delle migliori app per uso personale e per piccoli progetti. Inoltre, ha ottime capacità di monitoraggio dei tempi e fatturazione.

Processo n. 4: come controllare l’ambito del progetto

Non è sufficiente identificare il 100% dell’ambito del progetto all’inizio . Quel 100% cambierà durante la durata del progetto.

Quindi, hai bisogno di un modo per monitorare, controllare e apportare modifiche allo scopo.

La cura è ben nota. È una struttura di suddivisione del lavoro.

Bene, anche tu hai bisogno di un flusso di lavoro chiaro per introdurre modifiche a tutte le aree del progetto ogni volta che la quantità di lavoro cambia.

Tuttavia, si tratta di un processo di gestione del cambiamento integrato.

Allora, qual è il problema?

Hai bisogno di una WBS di alta qualità. Inoltre, è necessario un modo non nerd per descrivere l’ambito del progetto. Pertanto, è necessaria anche una dichiarazione dell’ambito del progetto. Ne parleremo di seguito.

Se stai lavorando a un progetto agile, l’ambito di incremento o iterazione chiaramente definito è ancora più vitale. Non pensare che agile ti eviti di documentare in modo approfondito il lavoro da svolgere. Mantieni in ordine il tuo Sprint Backlog e le User Story. Applica una semplice regola: “Un nuovo arrivato dovrebbe capire cosa è necessario fare dalla descrizione della User Story”.

Come convalidare l’ambito

Di tanto in tanto, è necessario ottenere un formale approvare che un risultato soddisfi le aspettative degli stakeholder.

È fondamentale farlo continuamente durante tutto il progetto.Anche se stai conducendo un progetto basato su un piano, nulla dovrebbe impedirti di fornire incrementi di prodotto per la revisione.

Perché ne hai bisogno?

Non vuoi ottenere tutto le richieste di modifica, tutti i difetti e alla fine “piccole modifiche al progetto”.

Ti priverai dell’opportunità di integrare effettivamente una modifica nel progetto.

Più sei vicino alla chiusura del progetto, meno tempo e risorse rimarranno. Inoltre, le parti interessate saranno meno inclini a negoziare modifiche all’ambito, alla tempistica o al budget. Inoltre, eserciteranno maggiore pressione sul team per ottenere ciò di cui hanno bisogno.

Semplicemente affermando l’ovvio:

È estremamente importante avere un ambito di progetto chiaramente descritto e approvato sin dall’inizio.

Quando un deliverable non soddisfa le aspettative, ci saranno correzioni.

È tua responsabilità dimostrare se una correzione è una richiesta di modifica e, pertanto, dovrebbe essere integrata correttamente. In caso contrario, è un difetto e devi fare ammenda. A volte a tue spese.

Come convalidi effettivamente l’ambito con i clienti?

Su qualsiasi progetto, puoi utilizzare il Demo Meeting simile a Scrum.

Basta preparare una breve dimostrazione del risultato finale. Spiegare lo stato e il progresso del progetto corrente. Dopodiché, indica i difetti noti e le parti in lavorazione.

Inoltre, raccogli il feedback dal cliente. Successivamente, puoi fornire tutta la documentazione di supporto e i rapporti richiesti dalle tue politiche.

Conclusione:

Raccogli continuamente feedback dalle parti interessate. Negoziare i termini dell’introduzione di nuove richieste di modifica. Mantieni aggiornata la linea di base dell’ambito del progetto.

Ottieni il mio modello di gestione dell’ambito del progetto

Non inventare la ruota! Potrebbe essere costoso per te.

Fai clic sul pulsante in basso e ottieni il mio modello di riempimento degli spazi. Viene fornito con una guida alle risorse su tutto ciò che è necessario sapere sulla gestione dell’ambito.

Perché l’intero ambito La linea di base è fondamentale per il tuo progetto?

Di solito, un progetto inizia e riceviamo i requisiti in diverse forme.

Ad esempio: e-mail, PDF, riunioni, modelli, segnalazioni di bug, qualsiasi cosa .

E, naturalmente, non prepariamo una Carta del progetto o qualcosa di simile. Cattiva pratica!

Nella maggior parte dei casi, non discutiamo nemmeno del business case del progetto.

Di solito creiamo una struttura di suddivisione del lavoro.

Tuttavia, viene utilizzato solo internamente e non va mai al cliente. Quindi scomponiamo il lavoro in attività e stimiamo il progetto. Usiamo una tecnica di stima dal basso verso l’alto.

Ora arriva il primo controllo delle aspettative:

presentiamo le stime per il progetto.

Vedi, a quanto pare c’è un mancanza di trasparenza qui. Il cliente non sa quale lavoro abbiamo effettivamente stimato.

Se la stima è vicina alle aspettative del cliente, non approfondirà i dettagli. Questo perché è già pronto a spendere quella somma di denaro e tempo. Non vuole sprecare il loro tempo prezioso.

Ecco la verità:

Molte organizzazioni e project manager nascondono inefficienze dietro tali accordi silenziosi.

È un argomento per un post separato, ma è la causa principale di molti dei tuoi problemi.

Cosa succede dopo?

Iniziamo l’esecuzione del progetto! Prima o poi il cliente chiederà di aggiungere un altro pezzo di lavoro.

Dopodiché, troveremo una parte di lavoro non identificato. Successivamente, verranno visualizzati problemi di qualità. Consumeranno un sacco di tempo.

Tutto sommato, consegniamo una consegna per scoprire che abbiamo fatto qualcosa di sbagliato.

Ed è allora che il cliente ci informa che lui hai dimenticato qualcosa e dovrebbe essere aggiunto al più presto.

Credimi, lo provi più di una volta.

Definizione della linea di base dell’ambito

“La linea di base dell’ambito è la versione approvata di una dichiarazione dell’ambito, della struttura di suddivisione del lavoro (WBS) e del relativo dizionario WBS, che può essere modificato solo attraverso una procedura formale di controllo delle modifiche e viene utilizzato come base per il confronto. ” -PMBOK® Guide

Che cos’è una dichiarazione sull’ambito del progetto?

Definizione della dichiarazione sull’ambito del progetto

La dichiarazione sull’ambito del progetto è una descrizione narrativa di un prodotto e l’ambito del progetto.

Viene utilizzato come conferma scritta di ciò che il tuo progetto produrrà e come.

Qual è la chiave per una dichiarazione preziosa sull’ambito del progetto?

Credo che sia necessario utilizzare termini e linguaggio comprensibili a tutti gli stakeholder. Questa parte della linea di base dell’ambito del progetto è principalmente per il cliente.

OK, cosa dovrebbe essere incluso?

Giustificazione di un progetto

È una breve descrizione di le esigenze dell’azienda. A volte una frase è sufficiente. Il resto dovrebbe rimanere in una Carta del progetto

Scopo del prodotto

È una descrizione delle caratteristiche, dei tratti e della funzionalità di un prodotto o di un servizio che produrrai.

Tieni presente che hai raccolto requisiti da diverse parti interessate. Quindi, non dare per scontato che tutti tengano traccia di ogni requisito. Inoltre, non è sempre chiaro quanto lavoro sia necessario per soddisfare un requisito.

È il luogo principale per allineare le aspettative degli stakeholder chiave.

Devi mostrare la quantità e la complessità del lavoro necessario per soddisfare le diverse esigenze. Pertanto, dedica il massimo impegno a questa sezione.

Criteri di accettazione

Sono le condizioni che devono essere soddisfatte prima che i risultati del progetto siano accettati.

Puoi includere un livello accettabile e anche qui il numero di difetti.

Deliverables

È una descrizione di tutti i deliverable che il tuo progetto produrrà.

Può includere il prodotto o servizio, documentazione di progetto, manuali di prodotto, materiale didattico per il prodotto, ecc.

Esclusioni di progetti

Qui è necessario specificare cosa non rientra nell’ambito del progetto.

Abbastanza spesso, una parte degli stakeholder vuole qualcosa di specifico. L’altra parte delle parti interessate o un cliente non lo supporta.

Pertanto, è una situazione di conflitto. Una volta che il conflitto è stato risolto e si è deciso di rimuovere qualcosa dall’ambito del progetto, inseriscilo qui.

Sii specifico e molto chiaro al riguardo. Risparmia tempo in futuro.

In primo luogo, non dovrai rivisitare nuovamente queste esclusioni di progetti. Gli stakeholder possono provare a includerli in un secondo momento durante l’esecuzione del progetto.

Tuttavia, a meno che qualcosa non cambi radicalmente, non dovresti perdere tempo a rivedere le esclusioni.

In secondo luogo, a meno che non sia chiaramente indicato, qualcuno potrebbe aspetto ancora che tu lo consegni. Non alimentare false aspettative. Sarà più facile consegnare il progetto alla fine.

Vincoli

Tutto ciò che ti limita a fornire il prodotto in modo efficiente dovrebbe essere indicato qui.

Presupposti

Sono le incertezze che non è stato possibile chiarire in questo momento.

È necessario accettarne alcune durante la pianificazione. Nel caso in cui un’ipotesi si dimostri non valida, avrai il diritto di modificare il piano del progetto.

Un cliente dovrebbe approvare la dichiarazione dell’ambito del progetto. In effetti, si tratta di un accordo formale e reciproco.

Inoltre, afferma che ti impegni a fornire i risultati descritti sotto il presupposto definito e con chiari vincoli. D’altra parte, il cliente accetta di accettare il risultato specificato.

Ciò non significa che non possiamo cambiare l’ambito del progetto. No. Significa che per apportare una modifica, dobbiamo modificare l’accordo.

Organizza l’ambito del progetto con WBS

WBS è una parte obbligatoria dell’ambito di riferimento su tutti i progetti. Grande o piccolo. Agile o basato sul piano.

Esiste già una guida completa a una struttura di suddivisione del lavoro sui principi di base del PM. Non lo ripeterò qui.

C’è solo un punto cruciale che voglio sottolineare:

I risultati finali descritti nella dichiarazione dell’ambito del progetto dovrebbero entrare in WBS così come sono. Mantieni i risultati coerenti durante tutto il progetto.

Inserisci tutto ciò che sai nel dizionario WBS

Dizionario WBS è un documento che descrive il lavoro che dovrebbe essere fatto per ogni pacchetto di lavoro.

In qualità di PM moderno, direi che dovrebbe far parte di un sistema di monitoraggio delle attività. La maggior parte del software di gestione dei progetti ti dà la possibilità di conservare queste informazioni in un unico posto.

Pertanto, non suggerirei di creare un documento separato. La manutenzione del dizionario WBS richiede molto lavoro. Cerca soluzioni integrate.

Puoi includere qualsiasi informazione che specifichi un componente nella WBS. Ad esempio, il dizionario WBS può includere:

• Descrizione del lavoro
• Presupposti e vincoli
• Persone o organizzazioni responsabili
• Traguardi
• Attività correlate
• Risorse richieste
• Stime dei costi o budget
• Criteri di accettazione
• Riferimenti ad altra documentazione

Quindi, qualunque cosa si adatta alle tue esigenze e ti aiuta a integrare WBS in altri processi.

Conclusione

“Non c’è vento che soffia giusto per il marinaio che non sa dove sia il porto.”

Non puoi portare il progetto a un esito positivo senza sapere cosa è necessario fare.

Ancora una volta, voglio sottolineare questo punto.

Anche se sei nell’ambiente Agile e l’ambito non è chiaramente definito per l’intero progetto, devi comunque pianificare un modo per definire, gestire, monitorare e modificare l’ambito del progetto.

Entrambi per un livello di iterazione e il risultato finale del progetto.

Consiglio anche di leggere:

• Articolo in primo piano: Come diventare un Project Manager IT senza esperienza
• Avanti nella serie: Guida definitiva su come creare una solida struttura di scomposizione del lavoro
• Precedente nella serie: Matrice di tracciabilità dei requisiti nella gestione dei progetti (ad es. ampio + modello)