Enterprise Project Management con Project Server 2016 – Parte 1 di 4

Parte integrante di SharePoint Server 2016, Microsoft Project Server consente di gestire il ciclo di vita di tutti i progetti aziendali in un’unica dashboard, mettendo a disposizione degli attori coinvolti (dai membri di team, ai Project e Program Manager, fino agli Executive) un flessibile strumento di collaborazione, monitoraggio e rendicontazione, personalizzabile secondo le specifiche esigenze di business.

In questa serie di articoli ci occupiamo di Project Server 2016, inizialmente – al fine di comprenderne il potenziale – inquadrandolo nel contesto dei processi di Project & Program Management aziendali, per poi approfondirne gli aspetti tecnici di implementazione e personalizzazione.

Questi i temi dei quattro articoli:

  1. La sfida dell’Enterprise Project Management
  2. Installazione e configurazione iniziale di Project Server 2016
  3. Prime customizzazioni di Project Server 2016
  4. Flussi di lavoro in Project Server 2016

La sfida dell’Enterprise Project Management

Cos’è un “progetto”?

Secondo il Project Management Book Of Knowledge (o PMBOK) edito dal Project Management Institute, (http://www.pmi.org/PMBOK-Guide-and-Standards.aspx):

“A project is a temporary endeavor undertaken to create a unique product, service, or result.”

Figura 1 – Sul comodino di ogni Project Manager…

Si dice anche che ogni progetto si distingue da tutti gli altri per una serie di caratteristiche che lo rendono unico. Fra queste:

  • Gli obiettivi di business che hanno portato alla concezione (prima) e all’approvazione (dopo) del progetto stesso,
  • I prodotti e risultati attesi,
  • Il contesto in cui si svolge,
  • Tempi previsti, costi stimati e risorse impiegate,
  • Attuatori e destinatari.

Progetti che sulla carta sembrano in tutto e per tutto simili fra di loro (ad esempio, l’installazione di una Farm SharePoint per la “Rossi SpA” e l’installazione di una Farm SharePoint per la “Verdi Srl”) non saranno mai identici: avranno punti in comune, questo è certo, ma da subito si potranno rilevare differenze sostanziali dovute magari alla disponibilità delle risorse del cliente, o al tipo di infrastruttura di virtualizzazione adottata, piuttosto che al budget messo a disposizione o al periodo temporale in cui il progetto dovrà chiudersi…

Il Ciclo di Vita del Progetto

Sebbene “unici”, però, tutti i progetti seguono un percorso strutturato in fasi, il cosiddetto Ciclo di Vita del Progetto, che si avvia con l’idea di sviluppare un prodotto o un servizio e si conclude con la realizzazione di tale prodotto o servizio.

Figura 2 – Il Project Life-Cycle

Esaminiamo in dettaglio queste quattro fasi.

Fase 1: Initiation

È la fase in cui si delineano le caratteristiche principali del progetto:

  • Obiettivi e destinatari,
  • Risorse interne ed eventuali partner,
  • Dove e quando.

Ma soprattutto:

  • “Sappiamo farlo?”
  • “Dovremmo farlo?”

Fase 2: Planning

La pianificazione è la fase in cui l’idea del progetto viene analizzata in ogni suo aspetto per definirne puntualmente:

  • Il piano (chiaro e definitivo) delle attività,
  • Lo svolgimento temporale,
  • Il team di progetto,
  • Il budget preventivo.

Il risultato più importante di questa fase è il Project Plan, descrizione in dettaglio del progetto e che di fatto ne guiderà la realizzazione. È in questa fase che il Project Manager avvia Microsoft Project, crea la prima bozza di piano di progetto, poi la raffina, la consolida e infine la condivide con il resto degli attori coinvolti (membri del team, Program Manager, executive, referenti del cliente o dei partner, eccetera).

Figura 3 – Microsoft Project 2016

Fase 3: Execution

Si passa dalla teoria alla pratica e vengono svolte le attività previste e declinate dal Project Plan.

Alcune di queste, ad esempio quelle che riguardano la gestione delle risorse, il monitoraggio dei costi, la comunicazione fra i vari interlocutori, partono contemporaneamente al kick-off del progetto e si estendono per tutta la sua durata. Altre, invece, si sviluppano solo per una parte del progetto (l’installazione di un server, la fase di test, il collaudo finale,…).

Fase 4: Closing

Un progetto si può ritenere “chiuso” solo quando sono stati completati i seguenti due task:

  • La consegna e l’accettazione dei prodotti o dei servizi realizzati;
  • La chiusura amministrativa del progetto.

È auspicabile che in questa fase si proceda anche ad una verifica finale corale (la cosiddetta lesson learned) in cui si ragioni sul raggiungimento dei risultati previsti, sugli eventuali punti di miglioramento, sulla ripetibilità in altri contesti, eccetera, al fine di trarre dal progetto un ultimo ricavo: quello della tesaurizzazione delle esperienze fatte.

I deliverable

Durante il Ciclo di Vita del progetto, in ciascuna delle fasi precedentemente illustrate, tutti gli attori coinvolti – chi in misura maggiore rispetto agli altri e chi in misura minore – sono responsabili della produzione, revisione, raccolta, distribuzione, protocollazione dei numerosi deliverable previsti (per convenzione e/o per contratto) e che sono di natura fondamentalmente documentale: l’ambito in cui si svolge il progetto definisce sia il tipo che la quantità di documentazione necessaria.

Figura 4 – Fasi del progetto e relativi tipi di deliverable

La governance di progetto, che si esprime attraverso le azioni di monitoraggio e controllo operate dal Project Manager, implica anch’essa produzione, revisione, raccolta, distribuzione, eccetera di specifica ed ulteriore documentazione.

Figura 5 – Monitoraggio e controllo = altri deliverable!

Ogni singolo progetto, quindi, coinvolge numerosi attori come protagonisti a vario titolo di specifici flussi comunicativi, flussi che implicano lo scambio di informazioni, flussi che se non procedono correttamente rischiano di frenare o addirittura impedire – certamente non agevolare – il raggiungimento di uno o più obiettivi. Il Project Manager ha come compito (anche) evitare che questo accada, verificando la validità e l’efficienza di tali flussi e rimuovendo gli impedimenti che ne inibiscono il regolare funzionamento.

Figura 6 – La visione del Project Manager…

A livello enterprise, poi, la questione diventa ancor più rilevante: missione del Program Manager è quella di monitorare tutti i progetti in essere (o per lo meno quelli che afferiscono ad un medesimo portafoglio), e utilizzare la sua visione d’insieme per collaborare con la dirigenza nella verifica del raggiungimento dei risultati previsti dalle strategie di business.

Figura 7 – …e la visione del Program Manager

La prospettiva “enterprise”

Il programma Microsoft Project è indiscutibilmente uno dei tool più avanzati per la gestione delle tre variabili intorno alle quali ruota il singolo progetto:

  • Tempi,
  • Costi,
  • Risorse.

Responsabilità del Project Manager è garantire all’azienda che il progetto di cui è responsabile sia portato a termine nel rispetto di tempi e costi stimati, gestendo nel contempo il team di risorse schierato.

Tutte le informazioni utili a questo scopo sono inserite, aggiornate, elaborate, all’interno del file Project dedicato al singolo progetto. Si può quindi dire che il file Project sia “autoconsistente” e più che adeguato per consentire al Project Manager di gestire la quotidianità del proprio ruolo.

Figura 8 – Microsoft Project in action!

Se però adottiamo una prospettiva più alta, una visione “enterprise”, ecco che si manifestano numerose altre esigenze di natura organizzativa e gestionale che travalicano abbondantemente i limiti del file Project:

  • I deliverable di natura documentale prodotti dal Project Manager, dai membri del team, dai fornitori esterni, dal cliente, dove vengono raccolti ed organizzati? Come vengono condivisi fra tutti gli attori? C’è un controllo delle versioni prodotte per ciascun documento? In che modo questi file possono essere messi a disposizione dell’auditor del Sistema di Gestione Qualità?
  • Come può un Program Manager avere una vista complessiva dell’andamento di tutti i progetti in corso? Quanto è agevole produrre dei report sintetici che raccontino di sovraallocazione delle risorse o di earned value basandosi sui dati relativi a tutti i progetti specifici di una business unit e aggiornati in tempo reale?
  • In che modo è possibile tenere traccia di problemi e rischi correlati a particolari task di progetto? Se ne può assegnare la risoluzione o la mitigazione ad un referente specifico per poi seguirne l’evoluzione durante l’intero arco temporale del progetto?
  • I Project Manager possono coinvolgere (pro)attivamente le risorse impegnate su più progetti dando loro visibilità sui task assegnati individualmente in modo che non vi siano ambiguità su tempi e obiettivi dichiarati?
  • Si può utilizzare Active Directory come repository centralizzato delle informazioni anagrafiche relative alle persone assegnabili ai progetti? Ne è possibile gestire l’allocazione tramite flussi di richiesta che prevedano l’approvazione formale da parte di un Resource Manager incaricato?

Stiamo parlando, gentili lettori, di Enterprise Project Management.

Microsoft Project Server

Microsoft Project Server è un Enterprise Project Management automation system, ovvero una piattaforma altamente personalizzabile che abilita la conduzione collaborativa dei progetti, integrata da strumenti di document management, di workflow, di analisi dei dati real-time e di rendicontazione.

Project Server, di fatto, nasce per rispondere a tutte le esigenze dell’azienda che intende affrontare la sfida dell’Enterprise Project Management: basato su SharePoint Server, ne eredita tutte le ben note funzionalità collaborative, tutti i meccanismi di gestione documentale (versioning, check-in/check-out), le automazioni, la sicurezza, la scalabilità, e via elencando, a cui unisce feature specifiche dell’ambito del Project & Program Management, progettate in base alle consolidate ed universalmente riconosciute linee guida descritte nel già citato PMBOK.

Nel prossimo articolo vedremo come installare Project Server 2016 all’interno di una Farm SharePoint Server 2016 e come affrontare il delicato tema della configurazione iniziale.