Migrazione delle risorse: pianificazione della capacità da Microsoft Project

Il valore di Project Server, per i PMO che lo gestiscono bene, raramente sono i piani di progetto in sé. Era lo strato operativo sottostante: un unico pool di risorse dell'organizzazione da cui attingeva ogni progetto, timesheet con costi che alimentavano la fatturazione e il riconoscimento dei ricavi, eccezioni di calendario che si propagavano da sole e viste tra progetti con cui i resource manager decidevano ogni settimana l'assegnazione delle persone su dati reali. È quello strato operativo che è in gioco. I piani si migrano. Lo strato operativo, spesso no.

Tre modalità di errore si ripresentano ogni volta che i PMO lo sottovalutano:

• La trappola del «le risorse le aggiungiamo dopo». Un team migra i piani in modo pulito e rimanda il pool di risorse allo sprint successivo. Quando arriva il momento, i responsabili di ogni progetto hanno già creato risorse duplicate nei loro progetti, e il resource manager ha perso l'unica fonte di verità che faceva funzionare le viste di capacità tra progetti.
• La trappola del «le tariffe di costo non sono critiche per l'avvio». Le tariffe standard vengono rimandate a una pulizia nella fase 2. Due mesi dopo, la Finanza scopre che la chiusura mensile richiede dati dei timesheet con costi che non esistono più nella nuova piattaforma, perché le tariffe non erano caricate al momento della registrazione delle ore. I dati non si possono ricostruire a posteriori; il riconoscimento dei ricavi si ferma.
• La trappola del «basterà Planner Premium». Un PMO dà per scontato che il prodotto cloud di Microsoft copra gli stessi casi d'uso. Per la modellazione delle risorse, non li copre. Planner Premium non ha un pool di risorse dell'organizzazione, né timesheet con costi, né una vista delle risorse tra progetti. Scoprirlo dopo la migrazione è troppo tardi.

La ragione strutturale di tutte e tre: il modello delle risorse è la parte di Project Server meno visibile in una demo di prodotto veloce e la meno coperta negli elenchi di confronto tra fornitori. I piani, i diagrammi di Gantt e le dashboard fanno bella figura in una demo. I pool di risorse dell'organizzazione, no. Per questo gli acquirenti danno poco peso alla copertura del modello delle risorse quando scelgono la piattaforma e scoprono il vuoto in produzione. Questa guida presenta prima il modello, poi la tattica di migrazione, partendo dal fatto che la decisione più importante è quale piattaforma di destinazione scegli.

Prima di decidere cosa migrare, fai l'inventario di ciò che hai. Il modello delle risorse di Project Server ha sei livelli, e ognuno si migra in modo diverso:

Non tutti i PMO usano tutti i livelli. La domanda giusta per l'inventario è «su quali di questi si basa davvero il nostro team per decidere?». Se non usi i timesheet con costi, il livello delle tabelle delle tariffe è decorativo; puoi farne a meno senza conseguenze. Se non usi le risorse generiche per modellare la domanda, puoi unirle. Se le usi per questo, quella capacità non è negoziabile nella piattaforma di destinazione.

Fai l'inventario prima di confrontare le piattaforme. Il risultato è un elenco di capacità indispensabili per la piattaforma di destinazione, e quell'elenco dà forma al resto della migrazione. La sezione successiva presuppone che tu abbia già quell'elenco.

I confronti tra piattaforme si restringono quando filtri per copertura del modello delle risorse. Ecco il quadro onesto, ordinato secondo i sei livelli visti sopra. Sì, parziale o no per ciascuno:

Il prodotto cloud di Microsoft (Planner Premium / Project for the Web, lo stesso prodotto con etichette di SKU diverse) lascia fuori quasi tutto il modello delle risorse. È una scelta di posizionamento deliberata: è uno strumento per le attività del team con uno strato di progetto, non una piattaforma per PMO. I PMO che usano seriamente il modello delle risorse di Project Server non possono sostituirlo con Planner Premium senza perdere capacità importanti.

Il modulo Resource Management di Smartsheet e Workfront conservano entrambi il concetto di pool dell'organizzazione. Differiscono nei dettagli: Smartsheet RM è uno SKU separato e aggiunge un costo notevole per postazione; il pool di Workfront è solido, ma il suo prezzo per postazione è il più alto dei quattro. Onplana non ha un pool di risorse separato: ogni persona è un membro dell'organizzazione, e il suo modello delle risorse è la capacità settimanale di quella persona in tutti i progetti (dal piano Professional), tariffe su tre livelli (persona, ruolo, valore predefinito dell'organizzazione) e calendari lavorativi con eccezioni con nome, senza componenti aggiuntivi a pagamento. Non ha risorse generiche, né calendari per persona, né una RBS formale. Il prezzo parte da 12 dollari per postazione al mese (Professional). Il confronto onesto con Planner Premium è nella nostra pagina di confronto con Planner.

C'è un'altra dimensione difficile da mettere in una tabella: la qualità della vista di capacità tra progetti varia molto tra le piattaforme anche quando la funzione di base esiste. Alcune mostrano solo le assegnazioni dirette alle attività; altre includono gli aggregati dei sottoprogetti; altre, l'allocazione dei segnaposto generici. Se il tuo resource manager decide ogni settimana l'assegnazione delle persone con questa vista, confrontala fianco a fianco durante la valutazione con le 25 risorse con più ore allocate.

Prima di esportare qualsiasi cosa, fai un inventario completo del modello delle risorse. È un inventario diverso da quello dell'elenco dei progetti: quello cataloga i progetti; questo cataloga lo strato delle risorse sottostante. Il risultato è un Report di Preparazione alla Migrazione delle Risorse che elenca ogni elemento delle risorse, dove si trova oggi, dove va e chi si occupa del trasferimento.

1. Elenco delle risorse con attributi. Esporta l'intero pool di risorse dell'organizzazione con nome, tipo (nominativa/generica/costo), email (per le nominative), unità massime, tariffa standard, ruolo/qualifica e percorso nella RBS. L'endpoint OData /Resources è la fonte di riferimento; il Reporting Database ha più campi derivati, ma solo in Project Server locale.
2. Tabelle delle tariffe di costo. Microsoft Project supporta fino a 5 tariffe di costo per risorsa (dalla tariffa A alla tariffa E) con intervalli di date di validità. Esporta ogni livello di tariffa e ogni riga di data di validità. Se il tuo PMO usa solo la tariffa A puoi ignorare B–E, ma verifica che sia davvero così prima di darlo per scontato.
3. Eccezioni di calendario. Per ogni risorsa, esporta l'elenco delle eccezioni di calendario con nome, intervallo di date e orario modificato. Se la tua piattaforma di destinazione non conserva le eccezioni con nome, salva i nomi in un CSV complementare così che il motivo («Settimana del congresso», «Chiusura per ferie») resti.
4. Gerarchia RBS. Esporta la struttura di scomposizione delle risorse: ogni nodo, i legami padre-figlio e le risorse assegnate a ogni nodo. La gerarchia è ciò che permette ai resource manager di filtrare le viste di capacità secondo la loro struttura di reporting.
5. Assegnazioni attive. Fai un'istantanea di ogni assegnazione attiva in ogni progetto attivo: quale risorsa, quale progetto, quale attività, ore allocate, ore effettive, inizio e fine pianificati. È la base della convalida; dopo la migrazione confronterai l'allocazione in origine e in destinazione.
6. Campi personalizzati delle risorse. Se il tuo PMO ha definito Enterprise Custom Fields sulle risorse (livello di nulla osta di sicurezza, indicatore di fatturabilità, tipo di contratto), esportali insieme all'elenco delle risorse. Alcune piattaforme di destinazione li modelleranno come campi integrati, altre come campi personalizzati e altre non li supporteranno; questo decide poi la mappatura dei campi.

Il Report di Preparazione completato è la base del resto della migrazione. Per verificare la qualità dell'esportazione prima di impegnarti, fai passare un pool di esempio nello strumento di anteprima della migrazione: carica una porzione rappresentativa del pool di risorse e guarda esattamente quali campi, tariffe ed eccezioni si trasferiscono in modo pulito.

Cinque fasi, ognuna con un risultato e un punto di controllo per decidere se proseguire. Il tempo totale è di solito di 3–5 settimane per un pool di 100–250 risorse, di più se hai tabelle delle tariffe di costo molto personalizzate o una RBS grande.

Fase 1: Inventario e decisioni (1 settimana)

Completa l'inventario preliminare descritto sopra e poi decidi la piattaforma in base a quali livelli del modello delle risorse non sono negoziabili per il tuo team. Documenta la decisione con le sue ragioni; è la sezione che rileggerai quando qualcuno chiederà perché la piattaforma scelta non ha la funzione X.

• Fare l'inventario sul tenant in uso
• Valutare ogni piattaforma di destinazione rispetto al tuo elenco di livelli indispensabili
• Scegliere la destinazione e documentarne le ragioni
• Ottenere l'approvazione della direzione del PMO per la piattaforma scelta

Punto di controllo: Report di Preparazione firmato; piattaforma di destinazione scelta.

Fase 2: Esportare il pool (2–3 giorni)

Esporta da Project Server finché è ancora in funzione e verifica poi che l'esportazione contenga ogni livello dell'elenco. Non affidarti alle esportazioni dei file .mpp per il pool di risorse; contengono solo le assegnazioni delle risorse locali del progetto, non il pool dell'organizzazione con le sue tariffe, i calendari e la RBS.

• L'elenco delle risorse, da /Resources
• Le eccezioni di calendario, da /Resources/Calendars
• Le tabelle delle tariffe di costo (o il Reporting DB, in locale)
• La RBS, dagli endpoint dell'API SOAP, che non hanno un equivalente in OData
• Le assegnazioni attive, da /Assignments
• Conteggi che corrispondano al Report di Preparazione

Punto di controllo: il conteggio esportato corrisponde a quello del Report di Preparazione per ogni livello.

Fase 3: Rimodellare nella destinazione (3–7 giorni)

Importa il pool nella piattaforma di destinazione e risolvi livello per livello le lacune di trasferimento emerse dal confronto tra piattaforme. Le risorse generiche che non si trasferiscono vengono rimodellate come segnaposto nominativi. I nomi delle eccezioni di calendario che non si trasferiscono vengono archiviati. I campi personalizzati delle risorse vengono mappati su campi integrati o su definizioni di campi personalizzati nella destinazione.

• Importare l'elenco delle risorse (importazione massiva o API della destinazione)
• Ricreare la gerarchia RBS e assegnare le risorse ai loro nodi
• Caricare le tariffe standard e le tabelle delle tariffe di costo prima di caricare qualsiasi assegnazione
• Applicare le eccezioni di calendario per risorsa
• Trasferire le risorse generiche secondo il modello della piattaforma
• Mappare i campi personalizzati delle risorse

Punto di controllo: conteggio del pool, gerarchia RBS e conteggio delle tabelle delle tariffe corrispondono all'origine.

Fase 4: Assegnare e convalidare (1 settimana)

Migra le assegnazioni delle attività progetto per progetto, a ondate raggruppate per team responsabile. Dopo ogni ondata, il team ricevente convalida l'allocazione in destinazione rispetto all'origine per i propri progetti entro 48 ore. Non andare avanti finché l'ondata non risulta pulita; inseguire scostamenti di allocazione accumulati su molti progetti è molto più difficile che correggerli progetto per progetto.

• Migrare le assegnazioni a ondate di 10–25 progetti
• Differenza di allocazione per risorsa e progetto: origine rispetto a destinazione
• Indagare qualsiasi scostamento > 5%
• Riconciliare i calcoli dei timesheet con costi su un campione di timesheet passati

Punto di controllo: differenza di allocazione per risorsa < 5% in tutti i progetti.

Fase 5: Viste di capacità e riconciliazione (1 settimana)

Ricrea le viste di capacità che i resource manager usano davvero ed eseguile in parallelo con Project Server per almeno 5 giorni lavorativi. I report giornalieri delle differenze segnalano ogni punto in cui il calcolo della capacità della nuova piattaforma differisce da quello della vecchia. Indaga ogni differenza. Documenta le differenze reali come limitazioni note.

• Ricostruire le 5 viste di capacità principali nella destinazione
• Generare report giornalieri delle differenze per le 25 risorse con più ore allocate
• Indagare gli scostamenti > 5%; documentare le differenze reali tra piattaforme
• Formare i resource manager sulla nuova interfaccia delle viste di capacità
• Passaggio: la destinazione diventa la fonte di verità, Project Server passa in sola lettura

Punto di controllo: 5 giorni lavorativi consecutivi di report giornalieri delle differenze puliti; i resource manager approvano la nuova interfaccia delle viste di capacità.

Le cinque modalità di errore del modello delle risorse che si presentano più spesso, con la prevenzione per ciascuna:

Lo schema comune a tutti e cinque: ognuno è una decisione del tipo «ci penseremo dopo» che costa poco sul momento e molto in produzione. Il lavoro di riconciliazione è uno dei costi più sottovalutati nei budget iniziali; nel calcolatore dei costi di migrazione rientra nel funzionamento in parallelo.

La fase di convalida prevede tre verifiche, e ognuna produce una prova. Archiviale con il Report di Preparazione; insieme formano la traccia di audit della migrazione.

1. Riconciliazione dell'allocazione per risorsa. Per le 25 risorse con più ore allocate nei prossimi 90 giorni, confronta l'allocazione in origine e in destinazione. Tolleranza: ±5%. Uno scostamento maggiore significa che la migrazione delle assegnazioni ha perso dati o che il calcolo della capacità della destinazione differisce strutturalmente da quello di Project Server. Entrambe le cose vanno indagate. Prova: un report delle differenze per risorsa.
2. Riconciliazione di un campione di timesheet con costi. Scegli i 10 timesheet chiusi più recenti di 5 risorse diverse. Ricalcola il costo nella destinazione con le stesse voci di tempo. Tolleranza: ±1% (sono soldi; la tolleranza è più stretta di quella dell'allocazione). Uno scostamento > 1% indica una tariffa errata, un'eccezione di calendario persa o entrambe. Prova: i calcoli dei costi fianco a fianco.
3. Parità delle viste di capacità tra progetti. Riproduci le 3 viste di capacità che i resource manager usano di più. Confrontale con l'ultima esecuzione di Project Server per lo stesso periodo. È normale che le due viste classifichino l'allocazione in modo diverso (diretta o di sottoprogetto, nominativa o generica). Documentalo come differenze note tra piattaforme nel manuale post-migrazione. Prova: schermate fianco a fianco con le differenze documentate.

Il risultato della fase di convalida è un Report sul Risultato della Migrazione con ciò che è stato migrato, ciò che non lo è stato e ciò che resta aperto. Insieme al Report di Preparazione della fase 1, i due documentano la traccia di audit completa.

Il PMO è responsabile del manuale di migrazione, ma il modello delle risorse ha conseguenze che i team finanziari scoprono dopo il passaggio se nessuno le solleva prima. Tre schemi si presentano in ogni migrazione con risorse a costo, e ognuno colpisce in modo diverso rispetto ai problemi lato PMO.

Tre concetti di tariffa che si confondono

Project Server gestisce tre tariffe distinte per risorsa che suonano simili e NON sono intercambiabili: la tariffa standard (il costo di un'ora interna per modellare l'allocazione, spesso il costo pieno del lavoro), la tariffa di costo (quella usata per calcolare il costo contabile di un timesheet, a volte suddivisa nelle tabelle delle tariffe da A a E per diversi tipi di attività) e la tariffa di fatturazione (quella addebitata a un cliente per le ore fatturabili di un incarico). Alcuni PMO usano una sola tariffa per tutti e tre i concetti; altri, tariffe distinte per concetto; altri ancora, livelli di tabelle delle tariffe all'interno di ogni concetto.

Prima di esportare, chiedi alla finanza quali concetti di tariffa usa davvero, quali livelli delle tabelle corrispondono a quali attività e quali campi della piattaforma di destinazione alimenta ogni tariffa. L'esportazione è una riga per tariffa e risorsa; l'importazione è una decisione di mappatura che determina se i report sul riconoscimento dei ricavi del prossimo trimestre tornano. Un errore comune e recuperabile è caricare le tariffe di fatturazione nel campo della tariffa di costo. I timesheet con costi vengono allora calcolati con la tariffa di fatturazione, i report sui risultati mostrano costi gonfiati e la soluzione è esportare e ricaricare di nuovo. Un errore peggiore e più difficile da correggere è caricare le tariffe di costo nel campo della tariffa di fatturazione. Le fatture emesse con la tariffa sbagliata vanno riemesse, e la conversazione correttiva con il cliente non è gratuita.

Le regole di capitalizzazione non si trasferiscono da sole

I PMO di organizzazioni regolamentate o con molti investimenti hanno spesso politiche di capitalizzazione del lavoro che dicono «le ore di ingegneria sui progetti capitalizzabili confluiscono in un'attività di bilancio invece che in una spesa». In Project Server queste regole vivono di solito come viste o report costruiti sul feed OData, a volte con un indicatore per progetto e uno per attività. Niente di quell'infrastruttura si migra da solo. Gli indicatori si esportano (valori di campi personalizzati); le viste e i report, no. La finanza deve ricostruire da zero i report di capitalizzazione nella nuova piattaforma, sugli stessi dati contrassegnati.

Il rischio è un trimestre silenzioso in cui i report di capitalizzazione non sono stati ricostruiti, ore che andavano capitalizzate sono finite in spesa e il periodo chiude con cifre errate. Gli errori rilevanti qui sono un rilievo di controllo interno. Chiedi alla finanza di impostare la ricostruzione della capitalizzazione come una linea di lavoro parallela alla migrazione, non come un seguito, e subordina il passaggio ad almeno un periodo chiuso di report di capitalizzazione fianco a fianco che tornino.

I report sull'utilizzo fatturabile richiedono una configurazione esplicita

I PMO dei servizi professionali vivono di utilizzo fatturabile (ore fatturabili divise per ore retribuite, per risorsa e in totale). Project Server lo ottiene combinando i dati dei timesheet con un indicatore «fatturabile» sull'assegnazione o sull'attività. L'indicatore si esporta in modo pulito; il report, no. Come mostra la matrice di confronto sopra, il supporto ai report nativi sull'utilizzo fatturabile varia a seconda della piattaforma di destinazione. Onplana, Smartsheet RM e Workfront offrono il report come elemento di primo piano; Planner Premium di Microsoft non ha il concetto di fatturabile.

Per i PMO che migrano a una piattaforma che supporta l'utilizzo fatturabile, subordina il passaggio a un report fianco a fianco delle ultime 4 settimane che torni entro ±2%. Qualsiasi scostamento maggiore indica un errore di mappatura delle tariffe, un indicatore di fatturabilità mancante o un'assegnazione non migrata. Per i PMO la cui piattaforma di destinazione non supporta nativamente l'utilizzo fatturabile, prevedi di portare l'istantanea OData in uno strumento di BI a valle (Power BI, Looker, Sigma) e di ricostruire lì il report. In entrambi i casi, la finanza dovrebbe approvare l'esattezza del report prima di spegnere la vecchia piattaforma. Altrimenti la prima chiusura mensile nella nuova piattaforma è il momento in cui emerge la lacuna, che è il momento peggiore possibile.

Perché la finanza deve essere coinvolta prima del passaggio

In ogni migrazione in cui la finanza è entrata tardi si ripetono gli stessi tre problemi: le mappature delle tariffe vanno rifatte perché la finanza non condivideva la lettura del PMO su quale tariffa è quale; i report di capitalizzazione non sono stati ricostruiti e la prima chiusura trimestrale nella nuova piattaforma ha riportato in modo errato il lavoro capitalizzato; lo scostamento dell'utilizzo fatturabile ha superato la tolleranza del PMO perché la finanza applica regole diverse. Nessuno è un problema di piattaforma; sono tutti errori di coordinamento. La soluzione costa poco: includi la finanza come approvatore designato nella fase 1 (inventario) e nella fase 4 (assegnare e convalidare). La sua approvazione chiude il cerchio sulla mappatura delle tariffe, sui report di capitalizzazione e sulla tolleranza dell'utilizzo fatturabile. Senza di essa, il PMO consegna la migrazione e la finanza scopre il costo settimane dopo, quasi sempre durante una chiusura mensile e quasi mai con tempi che permettano di rifarla con calma.

La migrazione è il punto di partenza; la domanda nel lungo periodo è se la pratica di pianificazione della capacità del tuo PMO continua a funzionare nella nuova piattaforma. Quattro abitudini distinguono i team che mantengono il rigore da quelli che si perdono per strada:

• Unica fonte di verità, applicata. Il pool di risorse dell'organizzazione è il riferimento; creare risorse locali in un progetto è un segnale precoce di deriva. Alcune piattaforme permettono di bloccare il permesso di creazione per progetto. Usalo se è disponibile; altrimenti, fai una revisione settimanale che confronti gli elenchi delle risorse di ogni progetto con il pool dell'organizzazione.
• Revisione trimestrale delle tariffe. Le tariffe standard che restano 12+ mesi senza revisione si allontanano dal costo pieno reale del lavoro. I timesheet con costi si allontanano allora dalla realtà finanziaria. Fissa un ritmo trimestrale per rivedere le tabelle delle tariffe e aggiornarle.
• Disciplina con le eccezioni con nome. Le eccezioni di calendario si accumulano in silenzio. Una risorsa con 30 eccezioni con nome in 3 anni è normale; senza un ritmo di revisione, le eccezioni si fossilizzano. Ogni anno, rivedi il numero di eccezioni per risorsa ed elimina tutto ciò che supera il periodo di conservazione previsto dalla politica.
• Evoluzione della RBS. La gerarchia di reporting corretta al momento della migrazione invecchia man mano che l'organizzazione si riorganizza. Pianifica una revisione della RBS ogni 6 mesi all'interno del ciclo generale di revisione dell'assetto organizzativo, così che la suddivisione delle viste di capacità continui ad avere senso.

Le domande che i PMO fanno più spesso sulla migrazione del modello delle risorse. Lo schema FAQPage completo è nei dati strutturati di questo articolo, così che queste domande compaiano nella funzione «Altre domande» di Google.

Ingrandisci