Processo di sviluppo

Aspetti generali

Questo è il processo nel quale si producono effettivamente le cose. Si tratta di un processo molto semplice ma nel contempo molto sensibile al contesto. I principi del processo di sviluppo possono essere applicati a qualsiasi ambito di lavoro ed in sostanza si tratta semplicemente di un processo di delega da un livello della struttura organizzativa ad un altro.

In alcuni contesti questo può essere sostituito da un approccio specialistico, ad esempio nei progetti agile può essere sostituito da un processo di sviluppo scrum.

Gli obiettivi del processo sono:

  • Trasferire la responsabilità di un pacchetto di lavoro;
  • Eseguire il pacchetto di lavoro;
  • Trasferire la proprietà dei prodotti finiti.

 

 

Accettare un pacchetto di lavoro

Un pacchetto di lavoro può assumere molte forme. Può essere un intero progetto delegato da un team di gestione del programma ad un team di gestione del progetto; un sotto-progetto delegato da un team di gestione del progetto ad un fornitore; un singolo pacchetto di lavoro delegato ad un piccolo team.

Qualunque sia la dimensione del pacchetto di lavoro i principi restano gli stessi. Il pacchetto deve essere adeguatamente definito in termini di ambito e di criteri di prestazione. Entrambe le parti (chi trasferisce e chi riceve) devono essere chiare sia su ciò in cui consiste il pacchetto di lavoro sia sulla capacità di eseguirlo da parte del ricevente.

Nel caso in cui il trasferimento riguardi un progetto delegato da un programma, l’attività ‘autorizzare il lavoro’ può essere lo sbocco di un mandato di progetto o di un brief di progetto. In quest’ultimo caso, l’attività ‘autorizzare il lavoro’ è effettivamente la stessa del processo di identificazione.

Nel caso in cui il trasferimento riguardi un team di progetto o di programma che delega il lavoro ad un fornitore, ci saranno di solito implicazioni contrattuali inclusa la negoziazione dei termini del contratto riguardo all’ambito e alla prestazione.

Quando l’ampiezza della delega diminuisce, l’attività diventa di tipo più personale. Dipende dal manager capire le capacità e la disponibilità dei membri del team ad accettare il pacchetto di lavoro.

Qualunque sia il contesto, il team o il singolo individuo che riceve il pacchetto di lavoro ha la responsabilità di assicurarsi di comprendere ciò che è richiesto e di avere i mezzi necessari per eseguire il lavoro. Un’accettazione formale evita incomprensioni più tardi.

 

Eseguire il lavoro

L’attività riguarda soprattutto la creazione dei prodotti. La maggior parte dell’impegno sarà concentrata sulle funzioni e sui processi tecnici piuttosto che su aspetti univocamente di project, programme o portfolio management. La cosa importante qui è il collegamento bilaterale con l’attività ‘coordinare e monitorare lo stato di avanzamento’.

La persona cui è affidata la responsabilità principale del pacchetto di lavoro dovrà pianificare il lavoro ed avrà compiti di gestione appropriati all’ambito del pacchetto di lavoro. Durante l’esecuzione del lavoro questa persona monitorerà alcuni o tutti gli aspetti della qualità, schedulazione, risorse, costi e rischi così come specificato nell’atto di accettazione del pacchetto di lavoro. Le informazioni sullo stato di avanzamento devono essere trasmesse al livello superiore per il consolidamento con le informazioni provenienti da altri pacchetti di lavoro.

Si tratta di un esercizio bilaterale nel quale le informazioni provenienti dal livello più alto possono impattare la prestazione del lavoro, ad esempio cambiamenti approvati, ritardi di lavori connessi, cambiamenti di priorità e così via.

Questa connessione fra il monitoraggio e il controllo dei diversi livelli di un progetto, programma o portfolio rappresenta il centro vitale della organizzazione di gestione.

 

Consegnare i prodotti

La consegna dei prodotti del pacchetto di lavoro da parte dello sviluppatore è soggetta alle stesse variazioni legate al contesto che caratterizzano la delega iniziale. In alcuni casi, l’attività di consegna dei prodotti può effettivamente rappresentare l’intero processo di chiusura. In altri implicherà la conclusione di un contratto o forse semplicemente il ricevere, testare e accettare un prodotto creato da un singolo individuo.

Apposite registrazioni dovrebbero confermare che il prodotto è stato completato in maniera soddisfacente e trasferito.

 

Progetti e programmi

I processi del progetto o del programma in Praxis sono concepiti per essere utilizzati in contesti differenti. Nei progetti piccoli può non essere necessario un processo di sviluppo separato. Nei progetti più grandi il processo di consegna può rappresentare il lavoro delegato ad un team o a un appaltatore esterno. In un programma il processo di consegna è, in effetti, una versione riassuntiva del ciclo di vita del progetto come mostrato qui sotto.

 

 

 

In questo contesto l’autorizzazione del lavoro a livello del programma può essere uguale al processo di identificazione e/o al processo di definizione del progetto che ne fa parte. Una volta che il lavoro è stato accettato dal team di gestione del progetto, questo inizia ad eseguirlo, vale a dire che esegue il processo di consegna. Alla fine, il progetto consegna i suoi prodotti, che sono accettati dal programma, ed esegue il processo di chiusura.

Questo dimostra che la sequenza di base delle fasi del ciclo di vita e dei processi ad esse associati sono comuni a tutti i contesti. La differenza risiede nel fatto che nel lavoro complesso ci sono livelli dei cicli di vita più nidificati.

 

Grazie a E-quality Italia e a Project Management Europa per la traduzione

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
26th September 2014Reference to scrum development in agile projects added
Torna in cima