Gestione progetti, commesse e timesheet: guida completa a pianificazione, risorse e redditività

1. Project management, commesse e timesheet: che cosa sono e come si collegano

Il progetto è il lavoro da fare, con un obiettivo, delle date e un responsabile. La commessa è la stessa iniziativa letta come conto economico: cliente, valore, budget di costo e margine da difendere. Il timesheet è la registrazione del tempo che le persone dedicano a quel lavoro. Collegati, permettono di confrontare ciò che era previsto con ciò che è accaduto e di trasformare le ore in costi e margini.

Progetto e commessa

Per «commessa» non c'è una definizione formale condivisa: le fonti di settore la usano con significati vicini ma non identici, e questa guida adotta quella appena data. Dentro il progetto il lavoro si scompone in attività, raccolte in una WBS (WBS, Gantt e Kanban), ed è a quel livello che le persone registrano le ore. Le linee guida generali di metodo sono in ISO 21502:2020; la seconda edizione è una bozza iniziale (scheda ISO 21502).

Modello di lavoro di EcosAgile.

Esempio con dati di fantasia: commessa a corpo da 24.000 €, budget di 40 giorni a 400 € di costo medio al giorno, cioè 16.000 € di costo e 8.000 € di margine atteso. Il progetto è consegnato alla data concordata, ma le persone hanno registrato 55 giorni: 22.000 € di costo, margine 2.000 €. Il piano non mostrava ritardi, la commessa ha perso tre quarti del margine. Il margine a finire si calcola come in Controllo economico.

Il timesheet

Il timesheet registra il tempo di ogni persona su progetti, commesse e attività, in ore o in giorni, ed è collegato alla contabilità di gestione, alla fatturazione e al costo di progetto (parafrasi da Wikipedia, voce «Timesheet», CC BY-SA 4.0, consultata il 29/10/2026). Dettagli in Timesheet.

Pianificazione, consuntivazione, controllo

Pianificare è fissare prima ore, date, costi e ricavi attesi. Consuntivare è registrare dopo ciò che è successo. Controllare è mettere i due lati a confronto e decidere: correggere il piano, chiedere una variazione al cliente, spostare persone. Senza timesheet il costo del lavoro consuntivato è una stima a memoria, e il confronto arriva quando non si può più cambiare nulla.

Timesheet di progetto e rilevazione presenze

Tabella di lavoro di EcosAgile; non è consulenza legale.

La Corte di giustizia UE (causa C-55/18, 14 maggio 2019) ha stabilito che gli Stati devono imporre un sistema oggettivo, affidabile e accessibile per misurare l'orario giornaliero di ciascun lavoratore, lasciando loro le modalità (testo della sentenza). Il timesheet di progetto non coincide automaticamente con quella misurazione: un foglio con le sole ore attribuite ai progetti può non coprire tutto l'orario. Chi vuole usare lo stesso sistema anche per misurare l'orario verifica con consulente del lavoro e payroll che soddisfi i requisiti applicabili. Il tema è in Rilevazione presenze: guida completa.

In EcosAgile: la commessa è un'anagrafica a sé e può raccogliere più progetti; il progetto porta budget, persone e ore. Il timesheet di progetto è mensile, con inserimento giorno per giorno. Presenze, assenze e flusso verso lo studio paghe sono nel modulo Time; ore e costi di progetto in Project & Timesheet.

2. Il ciclo end-to-end di un progetto

Un progetto ben governato attraversa otto fasi: opportunità, budget e baseline, WBS e attività, staffing e capacity, esecuzione, timesheet, controllo economico, chiusura. Le prime quattro avvengono prima che qualcuno registri un'ora e fissano il riferimento con cui, dopo, si misura la realtà. Le ultime tre producono i dati che dicono se il lavoro rende quanto previsto e che cosa conviene correggere o ricordare.

Le fasi non sono una cascata rigida: la 5 e la 6 corrono in parallelo, e il controllo della fase 7 si ripete finché il progetto è aperto. Chi fa che cosa e quali dati nascono in ogni fase si legge nella tabella; gli approfondimenti sono nelle sezioni indicate.

Owner e dati per fase sono un modello di lavoro di EcosAgile, da adattare all'organizzazione.

Un esempio dall'opportunità alla chiusura

Esempio con dati di fantasia, una commessa a corpo di una società di consulenza. (1) Il cliente chiede la revisione del suo reporting: si stimano 60 giorni e si concorda un valore di 42.000 €. (2) Il budget è 60 giorni a 350 € di costo medio, cioè 21.000 €, con 21.000 € di margine atteso; si salvano ricavo, giorni e date. (3) La WBS ha tre work package: analisi 12 giorni, sviluppo 36, collaudo e consegna 12. (4) Si assegnano tre persone e dalla disponibilità di aprile si tolgono i quattro giorni di ferie già approvati di una di loro.

(5) A metà sviluppo il cliente chiede due report in più, a voce. (6) A fine aprile i timesheet approvati contano 44 giorni: analisi chiusa a 15, sviluppo a 29. (7) Il project manager stima altri 29 giorni di sviluppo, quindi 15 + 58 + 12 = 85 giorni a finire contro 60: 29.750 € di costo e margine atteso da 21.000 a 12.250 €. A commessa aperta si può ancora discutere i due report con il cliente. (8) A consegna avvenuta i giorni sono 88, il costo 30.800 €, il margine 11.200 €. Nelle note di chiusura: i report chiesti a voce vanno quotati a parte.

Dove il ciclo si rompe

Senza una baseline, cioè una copia del budget e delle date al momento dell'approvazione, il controllo confronta il consuntivo con un piano che cambia ogni settimana. Con i timesheet compilati a fine mese, il controllo guarda sempre il mese scorso. E un progetto che non si chiude continua a ricevere ore: la chiusura serve anche a fermare le imputazioni.

In EcosAgile: il ciclo documentato nei manuali segue questo ordine: Business Model, progetto con budget, allocazioni, timesheet, approvazione, Economics, tranche di fatturazione, stato Completato. Il Business Model valuta la fattibilità prima del progetto, con le risorse per ruolo a costo standard; un progetto Completato non accetta più ore. Una baseline congelata non è descritta nei manuali: le modifiche al progetto restano in uno storico consultabile. Vedi la pagina del software Project & Timesheet.

3. WBS, Gantt e Kanban: pianificare il lavoro

WBS, Gantt e Kanban rispondono a tre domande diverse. La WBS scompone l'ambito in parti gestibili e assegnabili: che cosa va consegnato. Il Gantt colloca il lavoro nel tempo, con durate e sequenze: quando. Il Kanban mostra in che stato è ogni elemento di lavoro e dove si accumula: come scorre.

WBS: scomporre l'ambito

La WBS è una scomposizione gerarchica dell'ambito in componenti gestibili, costruita dai deliverable e non dalle attività. Per la regola del 100% i figli sommano il padre, senza lavoro in più né in meno; il livello più basso è il work package, con un solo responsabile (articolo PMI del 18/08/2026). ISO 21511:2018 è la guida alle WBS per progetti e programmi (scheda ISO 21511); la seconda edizione al 29/10/2026 non è ancora pubblicata: è in fase finale e la data indicata, dicembre 2026, non è certa.

Esempio con dati di fantasia: portale ordini per un distributore, stime in giorni.

• 1 Portale ordini (52)
  • 1.1 Analisi (10): verbali delle interviste (4), specifica funzionale approvata (6)
  • 1.2 Sviluppo (30): anagrafica clienti e listini (8), carrello e ordine (12), collegamento al gestionale del cliente (10)
  • 1.3 Collaudo e avvio (12): verbale di collaudo (5), utenti formati (3), messa in produzione (4)

Qui il secondo livello è per fasi e il terzo per deliverable; il confine fra deliverable e attività (messa in produzione, formazione) si decide nel progetto.

I rami sommano 10 + 30 + 12 = 52, e i work package di ogni ramo sommano il ramo. Le ore si registrano a livello di work package: è una scelta di metodo di questa guida, non una prescrizione di PMI o ISO.

Gantt: tempo, durate, dipendenze

Il Gantt è un grafico a barre: attività in verticale, tempo in orizzontale, lunghezza della barra uguale alla durata. Nella forma originaria mostra solo le durate; i Gantt moderni aggiungono dipendenze e avanzamento (Wikipedia). Con le dipendenze si vede la catena che decide la data di fine, il percorso critico.

Kanban: flusso e lavoro in corso

Il Kanban è un metodo visuale: le schede stanno in colonne che rappresentano gli stati, si prende nuovo lavoro quando c'è capacità (logica pull) e si limita il lavoro in corso, il WIP. Nasce in Toyota alla fine degli anni Quaranta (Wikipedia). Non dà durate né scadenze. Approfondimento: il metodo Kanban.

La tabella è un modello di lavoro di EcosAgile, non uno standard. Le parti su Gantt e Kanban sono parafrasi da Wikipedia, voci «Gantt chart», «Diagramma di Gantt», «Kanban (development)», «Kanban» e «Work breakdown structure», CC BY-SA 4.0, consultate il 29/10/2026.

Si parte dalla WBS: un Gantt senza WBS ordina attività senza sapere se coprono tutto l'ambito. Poi il Gantt, se le date contano e le dipendenze sono note; il Kanban accanto, se il lavoro arriva a flusso.

In EcosAgile: un progetto può avere la consuntivazione diretta oppure la «Gestione Fasi / WBS»: gruppi, attività (Task) e milestone, con predecessore, budget in giorni e percentuale di avanzamento. Le ore si registrano sulle attività. Con la WBS compare il tab Gantt, con barre per attività e gruppi e scala da giorno ad anno. Anche la scheda Gantt di Capacity mese persone ha i pulsanti Slack e Percorso critico e mostra item, data di inizio, owner, durata e total slack. Gli item (richieste e backlog su progetto) hanno una vista Kanban a colonne per stato: riguarda gli item, non le attività della WBS. Vedi la pagina del software Project & Timesheet.

4. Timesheet: modelli, regole e workflow di approvazione

Il timesheet registra il tempo dedicato a progetti, commesse e attività; il modello, giornaliero, settimanale o mensile, decide ogni quanto lo si compila e lo si consegna. Più la registrazione è vicina al fatto, più il dato è preciso e più disciplina richiede; più è lontana, più l'ultimo giovedì del mese diventa una ricostruzione dalla mail. Qualunque cadenza si scelga, il dato resta in ordine grazie a regole di compilazione, causali, blocchi di periodo e approvazione.

Tre modelli a confronto

La tabella descrive tre modelli di metodo ed è un modello di lavoro di EcosAgile, non uno standard; pro e contro sono valutazioni nostre, non misure.

Esempio con dati di fantasia: in un mese di 21 giorni lavorativi (168 ore), Marta lavora su due progetti e su attività interne. Giornaliero: giovedì 4 ore su A, 3 su B, 1 interna. Settimanale, venerdì: 17 su A, 13 su B, 10 interne, in tutto 40. Mensile, il giorno 28: 70 su A, 60 su B, 38 interne, in tutto 168. I totali tornano; cambia la qualità dell'attribuzione e il momento in cui il controller vede che B ha già consumato il budget.

I modelli si combinano: l'ente di ricerca FBK, per esempio, consiglia la compilazione giornaliera e chiude entro mezzogiorno del secondo giorno lavorativo del mese successivo (determina 09/2023). La nostra posizione: registrare ogni giorno o, al peggio, ogni settimana, e consegnare a cadenza fissa. Il mensile puro regge solo quando il dato serve alle paghe e a nient'altro.

Quattro chiavi di qualità

• Regole di compilazione: campi obbligatori (progetto, attività, ore), unità (ore decimali), quando serve una nota. Poche e scritte.
• Causali: poche e con un significato scritto. Le ore non attribuibili a un cliente vanno in una voce esplicita, così non spariscono dal totale.
• Blocchi di periodo: dopo la consegna la persona non modifica; dopo l'approvazione si riapre solo con una traccia; un progetto chiuso non accetta ore.
• Completezza: le ore registrate si confrontano con quelle attese (orario meno assenze); il KPI è in KPI di progetto e di timesheet.

Il workflow: dipendente, manager, controller, payroll

1. La persona registra le ore e consegna entro la scadenza, con i controlli di completezza.
2. Il manager verifica coerenza con attività e budget, poi approva o rifiuta con un motivo.
3. Le ore approvate sono congelate: correzioni solo con riapertura tracciata.
4. Il controller usa le ore approvate per costi, consuntivo e fatturazione (controllo economico).
5. Il payroll riceve ciò che gli serve dal processo paghe (integrazioni).

Quando il timesheet lo chiede un terzo

Nei programmi finanziati dall'Unione europea le regole cambiano da bando a bando e si leggono sul bando. Per Horizon Europe la guida annotata della Commissione (versione 2.0 del 1° aprile 2025, art. 20) ammette una dichiarazione mensile dei giorni-equivalenti oppure un altro sistema affidabile che registri almeno tutto il tempo lavorato sull'azione, con registri firmati almeno ogni mese da chi lavora e dal suo responsabile (guida annotata; non è il contratto). Per FESR e FSE+, l'art. 55 del Regolamento (UE) 2021/1060 consente, per il personale a tempo parziale sull'operazione, una percentuale fissa del costo del lavoro, indicata in un documento del datore di lavoro, senza un sistema separato di registrazione delle ore. Le regole dei programmi italiani le verifica il controller.

Il timesheet di progetto attribuisce il tempo a commesse e attività e non coincide automaticamente con la misurazione dell'orario di lavoro, che ha un'altra finalità: per usarlo anche a quello scopo si verificano i requisiti con i consulenti, a partire dalla guida alla rilevazione delle presenze.

In EcosAgile: il timesheet è mensile, compilato giorno per giorno (singola voce o intervallo) e consegnato anche a metà mese. Gli stati sono Mancante, In compilazione, Attesa e Approvato. Approva il responsabile di progetto per le ore del proprio progetto, oppure il responsabile del team per l'intero timesheet, secondo la logica scelta.

5. Commesse e modelli economici: Time & Material, Fixed Price, Turn Key

Il modello economico di una commessa decide chi paga lo sforamento. Nel Time & Material il cliente paga le ore effettive a tariffe concordate e il rischio di extra-costi ricade soprattutto su di lui; nel prezzo fisso, a corpo o Turn Key, il corrispettivo è concordato in anticipo e ogni ora in più erode il margine del fornitore. Il timesheet serve in tutti i casi, ma per scopi diversi: nel primo a fatturare, negli altri a sapere quanto si sta guadagnando.

Che cosa distingue i tre modelli

Le tre etichette non hanno confini uniformi. In questa guida Fixed Price indica un corrispettivo fisso per un ambito definito; Turn Key lo stesso corrispettivo fisso con in più la responsabilità del fornitore sul risultato completo e funzionante, a prezzo e data concordati. Nel diritto dell'appalto «a corpo» e «a misura» hanno un significato proprio, diverso dal Time & Material: il contratto lo legge un legale.

La tabella è un modello di lavoro di EcosAgile, non uno standard pubblicato: dove le fonti non dicono, la cella riporta una nostra lettura. Sulla ripartizione del rischio vedi PMI, «Project contracts: vendor and buyer views» (2007); le righe su T&M e Turn Key sono parafrasi da Wikipedia, voci «Time and materials» e «Turnkey», CC BY-SA 4.0, consultate il 29/10/2026.

Stessa commessa, due contratti

Esempio con dati di fantasia: commessa stimata in 100 giornate, tariffa di vendita 600 € al giorno, costo standard 380 € al giorno. A preventivo il margine è 22.000 € (36,7%). A consuntivo le giornate sono 120, il costo 45.600 €. In Time & Material il ricavo sale a 72.000 €: margine 26.400 €, sempre 36,7%. In Turn Key il ricavo resta 60.000 €: margine 14.400 €, 24,0%. I 12.000 € di differenza sono il ricavo di 20 giornate che nel Turn Key non si fattura; il costo vero di quelle giornate è 7.600 € (20 × 380), ed è ciò che porta il margine da 22.000 a 14.400 €. Con un change order a 600 € al giorno per 15 giornate fuori ambito (9.000 €) il margine torna a 23.400 €, il 33,9%. Se invece, nel Turn Key senza change order, 10 giornate non sono state registrate, il margine che si vede sale a 18.200 € (30,3%).

In Time & Material lo sforamento non tocca la marginalità: il rischio sta nelle ore che il cliente contesta. Nel Turn Key sta tutto nel margine. La nostra posizione: un prezzo fisso senza ambito scritto e senza change order previsto è una scommessa, e il timesheet è lo strumento che ogni mese dice quanto la si sta perdendo. Il margine in corso d'opera è in Controllo economico, le formule in KPI di progetto e di timesheet.

In EcosAgile: i tipi di progetto sono Turn Key (nei manuali «a corpo o chiavi in mano», quindi sia il Fixed Price sia il Turn Key della tabella, con ricavo che matura in base alla percentuale di avanzamento), Time Material (ricavo da tariffe di vendita per persona o ruolo), Canone, Ticket e Ticket-Monte Ore. Il tipo governa il calcolo dei ricavi: non è una classificazione libera. Le ore a timesheet si registrano solo su Time Material e Turn Key; per gli altri tipi i costi passano da item o tranche.

In EcosAgile: sui Turn Key si possono registrare Change Order, cioè ricavi speciali con ambito, importo e stato; per ogni progetto ci sono tranche di fatturazione con data, importo, fase e stato (Pianificata, Da fatturare, Fatturata, Pagata, Inattiva). Servono a preparare e controllare i dati di fatturazione.

6. Staffing di progetto: chi lavora su che cosa

Staffare un progetto vuol dire decidere quali persone lavorano su quali attività, con quale ruolo e per quanto tempo. La scelta tiene insieme ruolo, competenze, disponibilità nel periodo e costo, e si rivede quando il progetto cambia. La parola ha anche un altro senso, quando indica un partner esterno che fornisce il team: qui si parla dell'assegnazione di persone dell'azienda ai progetti.

Chi, quanto e quando

Lo staffing risponde alla domanda «chi»; la capacity risponde a «quanto» e «quando». Si parte dai ruoli che il piano richiede (WBS e attività) e dalle giornate che il budget assegna a ciascuno, e solo dopo si cercano i nomi. Il costo previsto di una persona su un progetto è fatto di giornate per costo giornaliero: con il costo della persona cambiare il nome cambia il margine, con il costo standard del ruolo no (controllo economico).

Che cosa si guarda prima di assegnare

• Ruolo e competenze che il compito richiede, non il titolo in organigramma (competenze).
• Ore non ancora impegnate nel periodo, al netto di assenze pianificate e di altri progetti.
• Costo della persona o del ruolo.
• Effetto sulla persona: sovraccaricarla o darle compiti lontani dalle sue competenze danneggia lei e il progetto.

Chi decide

Il nome finale non dovrebbe spettare al solo project manager. Chi vede un solo progetto assegna volentieri la stessa persona brava a tre progetti insieme, e nessuno dei tre piani lo mostra. Il PM propone; conferma chi vede i carichi di tutti, che sia un resource manager o un referente HR. Ogni cambio di assegnazione lascia una traccia con la data, altrimenti a fine progetto non si sa chi ha fatto che cosa. Si ricorre a persone esterne quando, nel periodo, il residuo del gruppo non copre il fabbisogno e la competenza non si costruisce in tempo; costo e inserimento vanno nel budget.

Dal webinar EcosAgile: nel webinar EcosAgile sui processi HR people-centric il relatore descrive lo staffing come ricerca di persone con competenze, qualifiche ed esperienza adatte e con disponibilità non satura, per esempio cinque giorni il mese prossimo e dieci il successivo; la disponibilità dipende da orari di lavoro e assenze pianificate (minuto 03:03). È la posizione del relatore, non uno standard.

In EcosAgile: l'allocazione lega una persona a un progetto con ruolo, data di assegnazione, data di rilascio, tariffa e giorni di budget; senza data di rilascio vale fino a fine progetto, ed è riferita al progetto, non alla singola fase. Si può allocare per gruppo persone, che accoglie anche i nuovi assunti, e un elenco mostra le persone senza allocazione. Per registrare ore su un progetto la persona deve risultare allocata. Per cercare chi assegnare c'è la voce «Ricerca risorse» del menu Capacity plan, descritta in Project management basato sulle competenze; la vista dei carichi per persona è descritta in Capacity planning.

7. Capacity planning: disponibilità, saturazione e carichi

Il capacity planning confronta le ore che le persone possono dedicare ai progetti con le ore che i progetti richiedono, mese per mese. Dalla capacità teorica del calendario si tolgono festività e assenze e si ottiene la capacità netta; sottratto il lavoro già allocato, resta il residuo. La saturazione è il rapporto fra allocato e capacità netta: dice quanto una persona è già impegnata, non quanto lavora bene.

La cascata, in cinque passi

1. Capacità teorica: giorni da lunedì a venerdì del mese per le ore del profilo orario della persona. Un part-time a 4 ore al giorno ha metà di un tempo pieno a 8.
2. Festività: le ore dei giorni festivi che cadono nel mese.
3. Assenze: ferie, permessi, formazione già pianificata. Quello che resta è la capacità netta.
4. Allocato: ore pianificate sui progetti, più una quota dichiarata per il lavoro che non è di progetto (riunioni, supporto); se la ometti, il residuo risulta più grande del vero.
5. Residuo: capacità netta meno allocato.

Le fonti non coincidono: alcune sottraggono festività e assenze in un solo passaggio. Qui sono due, perché la festività è uguale per tutti e l'assenza è della persona, e a volte si sposta. Formula adottata: saturazione % = ore allocate ÷ capacità netta × 100. Il denominatore è la netta, non la teorica: ferie e festività non sono ore che qualcuno possa assegnare. Il tasso di utilizzo (ore consuntivate su ore disponibili nette), con le sue varianti, è in KPI di progetto e di timesheet.

Esempio con dati di fantasia: mese di 22 giorni da lunedì a venerdì, uno festivo. Anna e Chiara sono a tempo pieno (8 ore), Marco è part-time (4 ore). Anna ha 3 giorni di ferie, Marco 2 di permesso, Chiara 1 di formazione. Il team, sulla netta, è all'84,2%; sulla teorica sembrerebbe al 72,7%. Stesso lavoro, due numeri: per questo il denominatore va scritto.

Che cosa leggere

Marco è sovrallocato di 4 ore, e dal singolo progetto non si vede: ognuno dei suoi due project manager gli chiede 40 ore e nessuno somma. Si guarda la capacity per persona e per mese, poi si sposta lavoro, si ritarda o si cerca capacità altrove (risorse condivise). A fine mese si confronta l'allocato con le ore a timesheet: la distanza misura la qualità delle stime, se i timesheet sono completi (timesheet). Una soglia valida per tutti non esiste: i benchmark online (utilization 70-85%) non hanno fonte né campione, e il confronto utile è con i propri mesi, per ruolo.

L'organico su più anni è un altro livello: workforce planning. Ferie, permessi e profili orari: rilevazione presenze.

Dal webinar EcosAgile: nel webinar sui processi HR people-centric secondo il relatore il capacity planning vuole task e WBS, ma anche ferie, permessi, profili di lavoro e costi, e una consuntivazione «veloce e programmatica» (minuto 03:03). Posizione del relatore, non uno standard.

In EcosAgile: il menu Capacity plan ha tre voci: Ricerca risorse, Capacity mese persone e Capacity mese unità org. Capacity mese persone ha quattro schede e filtri per anno, società, unità organizzativa, persona, ruolo e sede; Pianificazione e Gantt hanno anche parametri propri: Capacity plan, con per ogni persona e mese i valori Act/Plan, teorico, assenza e delta; Saturazione, con capacità e saturazione per mese; Pianificazione, con una griglia per progetto, task, ruolo e anno, valori da gennaio a dicembre, totale, budget e delta, e lo stato WBS (Richiesta, Approvata, Respinto, Inattiva); Gantt, con i pulsanti Slack e Percorso critico. Descrizione ricavata dalle schermate dell'ambiente di sviluppo: la disponibilità nella versione in uso si verifica con EcosAgile. Act/Plan è il consuntivo da timesheet per i mesi passati e il pianificato per i futuri, e dipende dalla completezza dei timesheet. Le ore teoriche vengono dal profilo orario, che gestisce part-time e turni. Ferie e permessi richiesti da ESS, una volta approvati, finiscono nel timesheet. La formula di saturazione di questa guida è un modello di lavoro: prima di confrontare i numeri si verifica la definizione usata dalla scheda Saturazione.

8. Project management basato sulle competenze

Un progetto basato sulle competenze sceglie le persone anche per ciò che sanno fare, non solo per le ore libere. Ogni attività richiede competenze con un livello; ogni persona ne ha alcune; la capacità residua dice quanto tempo c'è. La scelta sta nell'incrocio: chi ha la competenza ma non il tempo, chi ha il tempo ma non la competenza, e dove conviene affiancare, formare o cercare fuori.

Dal compito alla competenza

Per ogni attività del piano si scrive che cosa richiede, con una scala corta: nessuna, base, autonomo, esperto. Quattro livelli definiti per iscritto reggono; con dieci nessuno si mette d'accordo su che differenza ci sia fra il sesto e il settimo. I dati sulle persone vengono da titoli, certificazioni, formazione ed esperienze. Una competenza dichiarata e mai verificata pesa meno di una confermata dal responsabile: chi la scrive e chi la conferma sono due persone, e conviene dirlo.

La matrice competenze per capacità

La matrice è un modello di lavoro di EcosAgile, non uno standard pubblicato; la scala dei livelli è la nostra proposta.

Esempio con dati di fantasia, con le stesse tre persone di capacity planning. Il compito: configurare e collaudare un'interfaccia dati, 40 ore nel mese. Richiede analisi dei dati a livello autonomo e collaudo a livello base.

Soluzione possibile: Anna 24 ore sull'analisi, Chiara 16 ore sul collaudo, 40 ore in tutto. A Chiara restano 24 ore di residuo, da usare se serve per affiancare Anna sull'analisi e crescere su quella competenza. Marco, il più esperto, non si tocca: è già oltre il 100%.

Skill gap e dipendenza dagli esperti

Il divario si colma con formazione o affiancamento quando i tempi lo permettono; altrimenti la competenza si cerca fuori (selezione e recruiting). Una regola pratica: ogni compito critico ha un esperto e un affiancato. Senza, gli esperti si saturano per primi, come Marco, e il progetto dipende da due nomi.

Che cosa può fare l'AI, e dove si ferma

Un sistema può proporre un elenco ordinato di persone per un'attività; resta un suggerimento. L'ordine vale quanto i profili che lo alimentano, e profili vecchi o incompleti producono proposte sbagliate con aria di precisione. Il project manager vede perché una persona è proposta, può scartarla e risponde della scelta; ogni tanto si guarda chi viene proposto sempre e chi mai. I dati sulle competenze sono dati personali: per privacy, AI Act e supervisione umana vedi la sezione Privacy, GDPR e AI Act della guida al recruiting.

In EcosAgile: la voce «Ricerca risorse» del menu Capacity plan cerca le persone in base a requisiti: tipo di valutazione (per esempio self-assessment), anno e mese, ruolo, ore minime di disponibilità nell'anno e una o più righe di area, categoria, competenza e livello di conoscenza. Il risultato è un elenco con un punteggio, le competenze che corrispondono e le ore disponibili mese per mese rispetto alla pianificazione sui progetti, con i valori negativi evidenziati; la ricerca si può salvare con un nome. Dal risultato si apre il dettaglio della persona: competenze con valutazione, anni di esperienza e ultimo utilizzo, confronto con le competenze previste dal ruolo (radar), qualifiche, CV, progetti e calendario delle allocazioni; la disponibilità in ore ha una legenda da Ottima a Nessuna. Descrizione ricavata dalle schermate dell'ambiente di sviluppo: la disponibilità nella versione in uso si verifica con EcosAgile. I dati sulle competenze sono il tema del software Talent.

9. Controllo economico: budget, consuntivi e marginalità

Il controllo economico di una commessa confronta tre quadri: il preventivo (budget e margine attesi), il consuntivo alla data (ore, costi, ricavi maturati) e la previsione a finire. Serve soprattutto il margine a finire, perché dice dove si chiuderà la commessa quando si può ancora intervenire. Il margine alla data da solo non dice dove si chiuderà la commessa. Le ore arrivano dal timesheet, i ricavi dal tipo di commessa.

Dal budget in giornate al costo

Il budget nasce in giornate per ruolo e diventa costo con un costo giornaliero. Le strade sono due: il costo standard del ruolo, uguale per chi lo ricopre, o il costo della singola persona. Per il controllo di commessa si sceglie il costo standard: il margine non dipende da chi ha lavorato e i costi individuali non circolano fra i project manager. Il costo reale si confronta a parte, in amministrazione; se la distanza cresce, si rivede lo standard. Formula del costo orario: KPI.

Preventivo, alla data, a finire

Margine alla data = ricavi maturati meno costi sostenuti. Margine a finire = valore della commessa meno costi sostenuti e costi ancora da sostenere. Delta margine = margine a finire meno margine di preventivo. Il costo residuo lo stima il project manager, ruolo per ruolo: se resta quello del preventivo, il margine a finire ripete il preventivo e non segnala nulla.

Esempio con dati di fantasia: commessa Turn Key da 80.000 €, costo standard 350 € al giorno, avanzamento dichiarato 50%. Preventivo: 100 giornate e 5.000 € di subappalto. Dopo quattro mesi: 62 giornate e 3.000 € di subappalto sostenuti; il project manager stima 118 giornate totali e 6.000 € di subappalto.

Modello di lavoro di EcosAgile, non uno standard. Ultima colonna: più = sforamento di giornate e costi, meno = peggioramento del margine.

Alla data il margine è 38,3% contro il 50,0% del preventivo, ma è un valore parziale: non dice dove si chiude la commessa. A finire il margine previsto è 32.700 €, 7.300 € in meno: 18 giornate in più (6.300 €) e 1.000 € di subappalto. Questo è il numero da portare alla riunione di commessa, con la causa accanto. Se le tranche fatturate valgono 24.000 €, restano 16.000 € di ricavo maturato da fatturare: due numeri diversi.

Prima di fidarsi dei numeri

Un consuntivo vale quanto il timesheet che lo alimenta: ore mancanti o non approvate fanno salire il margine (l'esempio è in Commesse e modelli economici), e la chiusura mensile del timesheet viene prima della lettura del margine.

Il trattamento contabile dei lavori in corso, cioè quanto ricavo si riconosce a bilancio mentre la commessa è aperta, resta fuori da questa guida: il metodo lo concorda il controller con il bilancio. L'earned value è un altro modo di leggere il confronto fra piano e consuntivo e richiede una baseline: si confrontano il valore del lavoro svolto (EV), il costo effettivo (AC) e il valore pianificato (PV). Lo scostamento di costo è CV = EV − AC, quello di tempo SV = EV − PV; gli indici sono CPI = EV ÷ AC e SPI = EV ÷ PV, e la stima a finire EAC = BAC ÷ CPI, dove BAC è il budget totale. Il PMI lo presenta come metodo utile, non come obbligo, anche per progetti piccoli (blog PMI, 31/08/2026, consultato il 29/10/2026). Per le linee guida di riferimento esiste la ISO 21508:2026 sull'earned value management, pubblicata a febbraio 2026 al posto dell'edizione 2018; la ISO 21512:2024 sull'attuazione si basa ancora sull'edizione 2018 (ISO 21508, ISO 21512); i testi delle norme non sono liberi e questa guida non li riproduce.

In EcosAgile: il Business Model, prima del progetto, stima risorse per ruolo a costo standard e ricavi dei servizi. Nel progetto il budget è in giornate (8 ore) e il costo si valorizza a costo standard del ruolo, che è il default, o a costo persona, scelto progetto per progetto.

In EcosAgile: Economics sintesi e dettaglio mostrano margine iniziale, alla data e a finire, con delta e percentuale. I dati si aggiornano ogni notte (situazione del giorno prima) e si rinfrescano a mano.

10. KPI di progetto e di timesheet

I KPI di progetto e di timesheet sono pochi numeri, ciascuno con formula, unità di misura, frequenza e un responsabile: utilizzo delle persone, saturazione pianificata, realization, margine, scostamento di ore e costi, avanzamento, costo orario, puntualità del timesheet. Le fonti non li definiscono allo stesso modo, perciò la prima operazione è scrivere quale definizione si adotta. Qui sotto c'è quella di questa guida, con le varianti e un esempio svolto.

Dove le definizioni cambiano da una fonte all'altra

• Utilization. Il denominatore è, a seconda della fonte, le ore disponibili, le ore totali o la somma di ore fatturabili e non fatturabili. Adottiamo le ore disponibili nette (teoriche meno festività e assenze, la cascata è in Capacity planning), sia per l'utilization sia per la sua versione billable.
• Realization. Tre significati: ore fatturate su ore lavorate; importo fatturato su importo a tariffa standard; incassato su fatturato. Adottiamo il secondo, perché funziona anche dove il prezzo non è a ore. Il terzo è un tasso di incasso e lo chiamiamo così.
• Margine. Calcolato sui ricavi. Il ricarico, che divide per il costo, dà una percentuale più alta sullo stesso lavoro e non va confuso con la marginalità.
• Scostamento. Consuntivo meno preventivo, con il segno più per lo sforamento. L'earned value definisce lo scostamento di costo al contrario (valore maturato meno costo effettivo, più = favorevole): se si usano i due metodi nello stesso report, il segno va dichiarato in ogni colonna.

La tabella dei KPI

La tabella è un modello di lavoro di EcosAgile, non uno standard pubblicato: formule adottate, frequenze e responsabili sono proposte da adattare.

Esempio svolto: una persona, un mese

Esempio con dati di fantasia: mese di 21 giorni da lunedì a venerdì, 168 ore teoriche per una persona a tempo pieno. Si tolgono 8 ore di festività e 16 di ferie: ore disponibili nette 144. Consuntivate 108 ore su progetti con ricavo e 12 su un progetto interno di formazione; pianificate nel mese 130 ore. Utilization: 120 / 144 = 83,3%. Billable utilization: 108 / 144 = 75,0%. Saturazione pianificata: 130 / 144 = 90,3%, capacità residua 14 ore. Con 168 ore al denominatore la billable utilization scenderebbe al 64,3%: stessa persona, stesso mese, un altro numero, perciò la definizione va scritta.

Valori «sani»: perché qui non ci sono

Online circolano intervalli giusti o sani per l'utilization e per il margine, che cambiano da una pagina all'altra: per il margine di commessa si trovano sia 25-40% sia 55-75%, con definizioni di margine diverse. Le pagine che li riportano non dichiarano campione né definizione del denominatore, e non li riprendiamo. Il confronto che regge è con i propri periodi precedenti, per ruolo e tipo di commessa, con la stessa definizione; se la definizione cambia, si ricalcola lo storico.

In EcosAgile: Analisi consuntivazione mostra per progetto e fase budget disponibile e residuo, giornate consuntivate, percentuale di consuntivo e FTE medi previsti e residui. Economics sintesi riporta margine iniziale, alla data e a finire; la dashboard Analisi economics mensile ha schede per tipo di progetto, progetto, cliente e fatturazione, quella di Analisi Timesheet per mese, persone e clienti, e i report del timesheet si esportano in XLS e CSV. Le formule di questa sezione sono un modello di lavoro, non campi del prodotto: si applicano sui dati esportati o sui report.

In EcosAgile: le notifiche del timesheet sono descritte in Workflow, mobile e collaborazione.

11. Workflow, mobile e collaborazione: ESS, MSS, promemoria e approvazioni

L'Employee Self Service (ESS) è lo spazio in cui la persona registra le proprie ore, chiede ferie e permessi e vede i propri dati; il Manager Self Service (MSS) è quello in cui il responsabile approva, controlla l'avanzamento e guarda i carichi del team. App mobile, promemoria e regole di approvazione servono a ridurre un solo intervallo, quello fra il lavoro svolto e il dato approvato: ogni giorno in più è un giorno in cui il controllo economico lavora su ricordi.

ESS e MSS guardano lo stesso dato

La separazione dei ruoli ha un senso preciso: chi inserisce non approva, chi approva non modifica. Il responsabile che corregge di sua mano le ore di un collaboratore toglie al dato la provenienza, e prima o poi qualcuno chiederà chi l'ha scritto. Meglio rifiutare con un motivo e far correggere a chi ha lavorato.

In EcosAgile: nell'ESS il timesheet mensile mostra i festivi già valorizzati e permette di inserire spese e di richiedere ferie e permessi dallo stesso foglio. Nel MSS il manager vede i progetti in corso, le allocazioni, il controllo dei timesheet delle risorse e le approvazioni di ore e spese; non si approvano le proprie spese, e il manager non modifica le ore. Per le ore, il responsabile di progetto approva quelle del proprio progetto oppure il responsabile del team approva l'intero timesheet, secondo la logica scelta (timesheet); è possibile indicare un approvatore secondario, e allora basta l'approvazione di uno dei due.

Mobile: registrare dove si lavora

L'app serve a chi non ha una scrivania: consulenti dal cliente, tecnici in trasferta, chi passa la giornata fra tre sedi. Registrare sul posto evita la ricostruzione del venerdì. Da fissare prima: se le ore si scrivono da app e da web, le correzioni devono lasciare traccia in entrambi i casi.

In EcosAgile: l'app timesheet permette di registrare il lavoro in mobilità, scegliendo fra le attività su cui la persona è allocata; i consuntivi inseriti da app si riconoscono nel timesheet e si possono correggere dalla funzione «Registrazione lavoro (APP)».

Promemoria e notifiche: sollecitare chi ha il problema

Un promemoria uguale per tutti si impara a ignorare. Funzionano di più tre momenti, ciascuno rivolto a chi può agire: a inizio mese a chi non ha cominciato, alla scadenza a chi non ha consegnato, dopo la consegna al manager che non ha approvato.

In EcosAgile: le notifiche mail standard sono tre: compilazione assente o sotto il 60% nella prima parte del mese, timesheet non consegnato, timesheet consegnato e non approvato (al manager). L'azienda può modificarle o disattivarle.

Approvazioni: approvare l'eccezione

Il rischio è l'approvazione a tappeto, con «seleziona tutti» e senza guardare. Se i controlli bloccano alla consegna gli errori evidenti (ore oltre il teorico, giorni vuoti), il manager ha il tempo per ciò che resta: un progetto che ha già consumato il budget, un'attività nuova, un'assenza incoerente. E se chi approva è assente, il processo deve nominare chi lo sostituisce prima della scadenza, non dopo.

Dal webinar EcosAgile sui processi HR people-centric: nel passaggio sul time management oltre le paghe, il relatore sostiene che una richiesta di ferie deve arrivare anche ai responsabili dei progetti e che il dato va inserito una volta sola, non due (paghe e progetti) (minuto 12:42). È la posizione del relatore EcosAgile, parafrasata dalla trascrizione, non uno standard.

12. Integrare progetti, HR, payroll, ERP e contabilità

Integrare il sistema di progetto con gli altri significa decidere, dato per dato, quale sistema è il proprietario e come lo passa agli altri, in modo che nessuno debba reinserirlo. Dall'HR arrivano anagrafiche, assenze e profili orari; dal progetto escono ore approvate, costi e ricavi di commessa; il payroll riceve presenze, assenze e straordinari; contabilità, controllo di gestione e BI ricevono commesse e consuntivi.

Quale dato, da chi, verso chi

La tabella è un modello di lavoro di EcosAgile: il proprietario di ciascun dato va deciso caso per caso, ma deve essere uno solo.

Lo scambio salta spesso sul codice commessa: l'amministrazione ne apre uno nuovo, nessuno lo riporta sul progetto, le ore finiscono su un codice sbagliato o non passano. Servono una tabella di corrispondenza, un registro degli scambi e una persona con nome e cognome che guarda gli scarti.

Esempio con dati di fantasia: a fine mese le ore approvate nel timesheet sono 1.640 e quelle arrivate al controllo di gestione 1.632. Mancano 8 ore: il registro degli scambi dice che appartengono a un codice commessa non ancora mappato, e il controller lo sa prima di chiudere il mese.

Dal webinar EcosAgile sui buoni pasto: un relatore EcosAgile spiega che le persone registrano le ore con il dettaglio di commessa e progetto e che su quelle stesse ore si calcolano i buoni pasto, anche senza passare dalle presenze (minuto 18:52). È un esempio di consuntivi di progetto riusati per un altro processo: parafrasi del relatore, non uno standard.

Payroll, contabilità e BI

Verso il payroll non va il timesheet di progetto così com'è: vanno presenze, assenze e straordinari nel formato che lo studio paghe accetta, e conta chi controlla il file prima dell'invio. Fra progetto e contabilità o ERP passano commesse, centri di costo, fatture e costi esterni, in una direzione o nell'altra. La BI legge i consuntivi: più i codici sono puliti a monte, meno pivot da riconciliare a mano.

Dal webinar EcosAgile sui processi HR people-centric: secondo il relatore l'integrazione serve soprattutto sui processi con più sinergie, non su tutti, e il dato aperto e interoperabile tramite API è indispensabile (minuto 10:00). Parafrasi dalla trascrizione; su quali dati le API siano disponibili si chiede a EcosAgile.

Caso cliente: NPO Torino ha sostituito un sistema di consuntivazione giudicato rigido con EcosAgile Project & Timesheet, partendo dalle sedi italiane con l'integrazione di presenze e assenze nel payroll di gruppo, a elaborazione mensile; in seguito il sistema è stato esteso al personale di USA e Canada (case study).

Note spese e trasferte di progetto

Le spese di un progetto sono un secondo flusso: devono arrivare alla commessa e, se riaddebitabili al cliente, entrare nella fatturazione. Rimborso al dipendente e regole di trasferta restano nella guida alla gestione di note spese e trasferte.

In EcosAgile: il flusso paghe sta nel modulo Time: da assenze, presenze e straordinari un job schedulato produce il file per lo studio paghe, scaricabile via SFTP o dalla pagina «Scarico file paghe». Il manuale elenca job di esportazione per Zucchetti, TeamSystem ed Essepaghe, oltre ad altri formati. Per l'anagrafica esistono API per inserire e aggiornare progetti, fasi/WBS e clienti, consultabili nella API Library con utenze per modulo; i report timesheet si esportano in XLS e CSV.

13. Più progetti, più società, più paesi: portfolio e risorse condivise

Quando le stesse persone lavorano su più progetti, non basta sapere se ognuno è in orario: bisogna decidere a quale dare le persone quando due lo reclamano nello stesso mese. La gestione di portfolio è questo: una regola di priorità scritta prima del conflitto, una vista unica delle persone condivise e, nei gruppi con più società o più paesi, regole chiare su chi sostiene il costo del lavoro di chi.

Priorità e risorse condivise

La regola di priorità va scritta quando nessuno ne ha bisogno. Un criterio possibile, da adattare: prima gli impegni con scadenza o penale, poi le commesse a corpo vicine alla consegna, perché il loro margine è il più esposto (Commesse e modelli economici), poi quelle a ore, per ultimi i progetti interni. Senza regola decide chi chiama per primo, e non sempre è il progetto che conta di più.

Dentro un singolo piano il conflitto non si vede: ogni project manager ha un calendario sensato, e sfora la somma sulla stessa persona. Chi arbitra deve vedere tutti gli impegni di ogni persona, mese per mese, contro la sua capacità netta (Capacity planning), non solo i progetti che segue.

La tabella è un modello di lavoro di EcosAgile, non uno standard pubblicato.

Più società e più paesi

In un gruppo una persona della società A lavora spesso su un progetto venduto dalla società B. Il lavoro va al progetto, il costo a chi lo sostiene, e il ricavo infragruppo va tolto quando si guarda il gruppo, altrimenti lo stesso lavoro conta due volte.

Esempio con dati di fantasia: B vende un progetto a 30.000 euro. Lo svolgono 10 giorni di persone di B a 300 euro (costo 3.000) e 20 giorni di persone di A a 350 euro (costo 7.000); A li addebita a B a 500 euro al giorno, cioè 10.000. Per B il margine è 30.000 meno 13.000, cioè 17.000 (56,7%); ad A restano 3.000. Per il gruppo è 30.000 meno 10.000, cioè 20.000 (66,7%), la somma di 17.000 e 3.000. L'addebito infragruppo lo fissano controller e consulenti fiscali.

Con più paesi cambiano festività, e quindi capacità netta, e le regole locali sull'orario, da verificare con chi le conosce. Con valute diverse il controller fissa prima la regola di cambio, poi si confrontano i margini. Per organico e scenari organizzativi c'è la guida su organigramma aziendale e workforce planning.

In EcosAgile: un progetto può essere intercompany, con un ente esterno di tipo Intercompany, e nei report si filtrano via i ricavi infragruppo. Una persona di una società può lavorare su un progetto di un'altra; i report si filtrano per società. Le allocazioni possono usare gruppi persone, e ci sono le viste Allocazioni correnti e Persone senza allocazione.

14. Documenti, deliverable e conoscenza di progetto

Oltre al lavoro, un progetto produce tre cose: deliverable da consegnare, documenti che ne fissano i termini (contratto, ordine, varianti) e conoscenza che resta nella testa delle persone finché qualcuno non la scrive. Tutte e tre vanno agganciate al progetto e, quando serve, alla fase: un documento di cui non si sa a quale commessa appartenga ha già smesso di servire. Firma e conservazione sono un altro tema, trattato nella pagina Document & Signature; qui conta il contesto di progetto.

Deliverable, versioni e varianti

Un deliverable ha un codice, un titolo, un responsabile, la fase a cui appartiene e un'accettazione del cliente. Per le versioni basta una regola minima: una sola versione corrente, riconoscibile dal nome o dalla data; le precedenti restano consultabili; si sa chi ha approvato che cosa e quando. Lo stesso vale per le varianti di contratto (Commesse e modelli economici): la variante firmata sta accanto al contratto, non in una mail del cliente.

La tabella è un modello di lavoro di EcosAgile, non uno standard pubblicato.

Conoscenza e lezioni apprese

La chiusura (Il ciclo end-to-end) è il momento in cui la conoscenza si scrive, perché poi la squadra si scioglie. Una riunione breve con il team, e una scheda di sei campi: che cosa è successo, effetto in ore o in euro, causa, che cosa cambiare, a chi serve la prossima volta, dove sta il documento. I numeri non si raccontano a memoria: arrivano dal confronto fra ore previste e consuntive per fase (Controllo economico). Le stime sbagliate, con lo scarto, sono la conoscenza che più si riusa nel preventivo seguente.

Storico e accessi

Lo storico serve a capire come si è arrivati a un numero: chi ha cambiato il budget, chi ha riaperto un timesheet, quando è stata chiusa un'allocazione. Gli accessi seguono i ruoli: chi lavora al progetto vede i documenti del progetto, il contratto con gli importi non è per tutti.

In EcosAgile: il progetto ha una scheda Documenti con due blocchi: Knowledge management, per i deliverable (codice, titolo, materiale, allegato o link, fase, referenti), e Documenti amministrativi, per contratti e ordini (nome, allegato o link, ente, stato). I Change Order dei progetti Turn Key hanno data, ambito, importo, stato e documenti. Le modifiche al progetto finiscono in uno storico consultabile, e il sistema registra anche consegna e approvazione dei timesheet, annullamenti e modifiche ad allocazioni. Gli item, cioè le richieste su un progetto, hanno schede Comunicazioni e Allegati. Firma elettronica e gestione documentale sono il tema della pagina Document & Signature.

15. Come scegliere un software di project management e timesheet

Un software di project management e timesheet si sceglie partendo dal proprio modo di lavorare: che tipi di commessa vendi, chi inserisce le ore e con quanta pazienza, quali numeri servono al controllo, con quali sistemi deve scambiare dati. Si fissano prima delle demo i criteri indispensabili e quelli preferibili, si prova il sistema su un progetto reale e si calcola il costo su più anni, non il solo canone.

Chi scrive è un fornitore di software: leggi i criteri sapendolo.

Parti dal consuntivo, non dal Gantt: in demo fa bella figura, ma con ore sbagliate o in ritardo margine e capacità sono decorazione. I criteri qui sotto mettono prima le ore.

Manuale o sistema integrato

Un foglio di calcolo e una mail il lunedì reggono finché una persona sola consolida tutto e le commesse sono dello stesso tipo. Il limite arriva col primo cliente che chiede il dettaglio o con la prima perdita scoperta a chiusura. Se l'ultimo giovedì del mese più persone ricostruiscono le ore dalla posta, l'hai superato.

La tabella è un modello di lavoro di EcosAgile, non uno standard pubblicato.

Checklist dei 18 criteri

Modello di lavoro di EcosAgile, non uno standard. La divisione è una proposta: sposta le voci secondo il tuo modello.

Indispensabili (11)

• Tipi di commessa reali (a ore, a corpo, canone, ticket) con la regola di ricavo di ciascuno
• Commessa, progetto e fasi con budget
• Inserimento ore semplice per chi lo fa ogni giorno, anche in mobilità
• Controlli di completezza e promemoria
• Approvazione: chi, quando, come si riapre
• Costo e ricavo con regole dichiarate (standard o reale, tariffe)
• Pianificato, consuntivo e margine nello stesso quadro
• Costi esterni e spese riaddebitabili sulla commessa
• Ruoli e permessi: chi vede costi e margini
• Esportazione completa e uscita dal sistema
• Costo su più anni, non solo licenza

Preferibili (7)

• WBS e Gantt
• Capacity per persona
• Competenze e ruoli per assegnare
• Integrazione con paghe, HR e contabilità (file o API)
• Report, pivot e dashboard esportabili
• Più società, più lingue, più paesi
• Avvio, formazione e assistenza

Domande da fare in demo (elenco di lavoro di EcosAgile)

1. Porta una commessa vera e fai inserire le ore a chi le inserirà davvero: conta i passaggi.
2. Correggi un timesheet approvato: che cosa succede, dove resta traccia.
3. Margine alla data e a finire di una commessa a corpo: con quale formula e con dati di quando.
4. Prova chi vede costi e margini con il profilo di un project manager e di un manager di linea.
5. Chiedi come escono i dati e come si collegano paghe e contabilità: formato, file o API, chi mantiene il collegamento.
6. Fatti scrivere che cosa c'è oggi, che cosa è su richiesta, che cosa è previsto.

La prova su un progetto reale e il costo nel tempo

Scegli un progetto in corso, due project manager e il controller, e scrivi prima che cosa vuoi vedere: ore giuste, chiusura del mese senza rincorse, margine uguale a quello del tuo foglio. Spiega ogni differenza, anche quando ha ragione il foglio.

Il costo si conta su più anni: avvio e migrazione dei dati, formazione, integrazioni, assistenza, evoluzioni, uscita. Conta anche restare dov'è: le ore di chi consolida i fogli ogni mese. Cifre qui non ce ne sono.

Guida, pagina prodotto e time-sheet.cloud

Questa guida spiega metodo, formule e criteri, validi anche se scegli un altro prodotto. La pagina EcosAgile Project & Timesheet descrive il prodotto. time-sheet.cloud è il sito dedicato allo stesso prodotto, per conoscerlo e chiedere una demo.

In EcosAgile: il timesheet è mensile, con inserimento giorno per giorno, e si approva dal responsabile di progetto oppure dal responsabile del team. Per ogni progetto il costo è lo standard del ruolo o quello della persona, e l'economics mostra margine iniziale, alla data e a finire, con dati aggiornati ogni notte. Per il confronto su un tuo progetto: richiedi una demo sul tuo processo o contatta il team.

16. Domande frequenti