Ruoli Funzionali vs Ruoli di profilazione in un software di gestione progetti

I software di Project Management, tra le varie funzionalità, permettono di definire, gestire ed attivare le persone che partecipano al team di progetto. L'accesso e la capacità di azione da parte degli utenti che accedono al sistema è regolato normalmente da due tipologie di ruoli:

• Ruoli funzionali
• Ruoli di profilazione (o ruoli di sistema)

In questo articolo andremo ad illustrare il significato delle due tipologie con l'obiettivo di far comprendere cosa le differenzia e perché devono esistere entrambe. Partiamo quindi col dare le loro definizioni.

Ruoli funzionali

I ruoli funzionali indicano le mansioni delle persone azienda, ossia l'incarico che ricoprono nell'ambito delle loro attività lavorative. Poiché ogni realtà necessita di figure professionali coerenti con il proprio ambiente di lavoro, i software più completi di Project Management, permettono la definizione in autonomia le anagrafiche di questi ruoli per rispecchiarne la struttura e l'organizzazione.

Inoltre, come è normale che sia, alcune persone in azienda possono ricoprire più incarichi ed la soluzione di project management adottata deve permettere quindi di assegnargli più ruoli funzionali ad una stessa persona. Nei software dovrebbe essere presente un accortezza che indichi quali ruoli funzionali sono preposti a gestire il progetto, a prescindere dal profilo di accesso utente. Questo per rendere il software il più flessibile possibile.

Ruoli di profilazione

I ruoli diprofilazione invece, sono quei ruoli che raggruppano un insieme specifico di permessi per l’interazione con le funzionalità presenti in un applicativo software regolato da un sistema di autenticazione. Questi ruoli sono quindi indipendenti dalla realtà aziendale, in quanto sono nativi del prodotto software. Questi ruoli vanno associati in fase di definizione del profilo dell'utente per permettere l'accesso al sistema.

Ad esempio, un ruolo Administrator molto probabilmente potrà gestire tutto il sistema software, a partire dalla profilazione utenti, attribuzione di permessi, gestione di configurazioni ed anagrafiche ecc. Viceversa, un ruolo Utente Base avrà accesso ad un'area limitata del software. Per una maggiore flessibilità, ed in presenza di diversi ruoli di profilazione in sistemi complessi, le applicazioni software dovrebbero prevedere la possibilità di gestire l'anagrafica utenti in modalità di multiruolo, ovvero un utente potrebbe avere più ruoli, a discrezione delle esigenze aziendali.

Importanza di entrambi i ruoli

Descritte le due tipologie e mostrate le caratteristiche che le differenziano, andiamo a svelare perché sia indispensabile averle entrambe definite a sistema nell'ambito del software di Project Management. Facciamoci aiutare da un esempio.

In un qualsiasi applicativo di Gestione Progetti è auspicabile che esistano come minimo i ruoli di profilazione di Project Manager e Project User. Il primo ruolo avrà sicuramente permessi di lettura, scrittura, cancellazione sul progetto e parti correlate quali wbs, team, milestone, pianificazione e schedulazione attività, etc.

I ruoli funzionali invece, poiché definiti dinamicamente ed in autonomia, possono essere qualsiasi, ma nell'ambito del Project Management, si auspica che sia stato definito almeno il ruolo funzionale di Project Manager.

Supponiamo ora che in un'azienda che utilizza un sistema di Project Management siano stati definiti venti utenti con ruolo di profilazione di Project Manager. Se ci fermiamo a questo livello, idealmente tutti i venti utenti possono gestire qualsiasi progetto creato nell'applicazione.

Chiaramente non deve essere così!

Ogni utente con questo ruolo dovrà accedere ai soli progetti di cui è veramente il Project Manager designato.

Come viene indicata questa informazione? Ecco che entrano in ballo i ruoli funzionali. È logico pensare che questi stessi venti utenti come minimo abbiano associato, per ipotesi, il ruolo funzionale Project Manager. A questo punto, in fase di definizione di un progetto deve essere possibile definire un team di progetto associando ad ogni risorsa del team il ruolo funzionale con cui parteciperà al progetto (per i soli utenti che hanno assegnato più di un ruolo funzionale).

La soluzione di project management adottata deve chiaramente supportare questa modalità in modo che l'abbinamento del ruolo di profilazione con il ruolo funzionale garantisca l'accesso ed i poteri esecutivi coerenti sul singolo progetto. In sistemi multi-ruolo e nel caso di progetti complessi questo permette la massima flessibilità nella definizione del team e delle operatività sui progetti di pertinenza, alcuni utenti possono essere infatti PM di un progetto e "semplici" partecipanti in un altro progetto.

Chiaramente quando si attribuiscono uno o più ruoli funzionali ad un utente, questi devono essere coerenti con i ruoli di profilazione a lui associati. Cioè, se un utente ha ruolo di profilazione Utente base, per cui può solopartecipare e consultare informazioni limitate dei progetti dei quali fa parte nel team, assegnargli il ruolo funzionale di Project Manager sarebbe incoerente (e il software negerebbe le opportune funzionalità di gestione del progetto stesso).

T-PPM Project Porfolio Management

Il Software T-PPM è il software di gestione progetti e gestionale delle attività che rispecchia pienamente quanto appena descritto! I ruoli di profilazione nativi, chiamati anche ruoli di sistema previsti sono:

• Project user: utente base che accede in lettura su informazioni limitate di progetto
• Project Manager: utente con permessi di lettura e modifica su progetti ed accesso a tutte le informazioni del progetto
• Project Manager RO: utente con permessi in sola lettura su progetti ed accesso a tutte le informazioni del progetto
• Project Administrator: utente che può creare i progetti ed associare il Project Manager ad un progetto
• Project Controller: utente che può consultare qualsiasi progetto a sistema senza poterli modificare

Ci sono altri ruoli di sistema nel software T-PPM che non indicheremo perché non rilevanti per questo articolo.

I ruoli funzionali invece, in T-PPM Project Management sono definibili in autonomia dagli amministratori di sistema tramite un pannello di gestione che gli permette di creare i ruoli funzionali a piacere, con la possibilità promuovere il ruolo funzionale a Project Manager, tramite un apposito flag.

Per un’azienda del settore informatico un esempio di ruoli funzionali potrebbero essere:

• Project Manager: a questo si attiva il flag che indica che è proprio un incarico di Project Manager.
• Software Architect
• DB Specialist
• Software Developer
• …….

T-PPM, Team e abbinamenti con le risorse

Nel software T-PPM Project Portfolio Management, l’abbinamento utenti, ruoli funzionali e progetti avviene tramite la creazione del team di progetto. Quindi, una volta creato il progetto, si associano le persone con uno o più ruoli funzionali, andando a comporre il Team di progetto.

Inoltre la partecipazione di una risorsa ad un team di progetto può essere raffinata inoltre indicando il periodo di validità in data: questo per far partecipare la persona, con quel ruolo funzionale, per quel progetto, in un intervallo di tempo preciso.

Per fare più chiarezza andiamo a descrivere il seguente schema qualitativo.

Facendo riferimento allo schema, abbiamo la tabella degli Utenti di sistema dove ad ognuno vengono attribuiti i Ruoli di Profilazione (colonna System Roles) nativi del software T-PPM Project Portfolio Management e pescati dalla tabella System Roles, ed i Ruoli Funzionali che sono definibili in autonomia dall’amministratore e vengono pescati dalla tabella Ruoli Funzionali. Gli utenti vengono relazionati con i progetti tramite la tabella Team di progetto dove viene indicato anche con quali ruoli funzionali partecipano.

Nello schema sono evidenziate in rosso le relazioni che andiamo a spiegare per comprendere ancora meglio quanto scritto finora. Vediamo che nelProgetto A l’utente Andrea M. partecipa con il ruolo funzionale di Software Architect: questo significa che, puravendo associato come ruolo di profilazione Project Manager, in questo caso non potrà gestire il progetto perché il Software Architet non ha la facoltà di potere amministrare i progetti, come si evince dalla tabella dei Ruoli Funzionali nella la colonna amministra.

Nello stesso team, Mario R., invece, partecipando con il ruolo funzionaleProject Manager che ha potere di amministrazione, e avendo anche ruolo di sistema di Project Manager, è l’effettivo amministratore del Progetto A.

Nel Progetto B, invece, Elena R., anche se ha come ruolo funzionaleassociato Project Manager, non potrà gestire il progetto, in quanto non ha l’adeguato ruolo di profilazione.

Il Project User è il ruolo base del Project Portfolio Management di TeraNet e ha solo il permesso di lettura deiprogetti di cui fa parte e l'accesso ad un insieme limitato di informazioni.

Conclusioni

Concludendo, in un sistema soprattutto multi-ruolo, per gestire gli accessi e le capacità di azione sui progetti per le persone facenti parte di un team di progetto non è sufficiente il solo utilizzo dei Ruoli di Profilazione. Riuscendo a dare una logica ai ruoli funzionali, ossia potendo indicare quali mansioni hanno anche la capacità di amministrare i progetti, è possibile "chiudere il cerchio" per ottenere come risultato un sistema coerente dove la visibilità delle informazioni e la loro gestione sono regolate dalla combinazione delle due tipologie.