Ore di progetto oltre il previsto: trova le cause

Partire da una domanda a cui il team può rispondere

«Perché questo cliente è meno redditizio?» sembra una domanda precisa, ma le ore da sole non bastano. Servono anche ricavi, costi di realizzazione e periodo di confronto. Una prima domanda più utile è: perché questo progetto a prezzo fisso ha richiesto 60 ore quando il contratto ne includeva 40, e le ore aggiuntive sono state fatturate?

Questo è un esempio fittizio. Atlas ha un progetto a prezzo fisso con 40 ore incluse. I dati aziendali ne riportano 60, di cui 20 attribuite a un intervento aggiuntivo di redesign. Una richiesta su Slack e il perimetro concordato spiegano che cosa è successo. I numeri illustrano un’indagine, non il risultato di un cliente.

1. Rendere confrontabili le registrazioni

Annotare cliente, identificativo del progetto, periodo di esecuzione e versione del contratto. Verificare che le 60 ore appartengano a questo progetto, non all’assistenza, a una fase precedente o a un altro account con un nome simile.

Separare le ore effettive dalle stime. Controllare anche registrazioni duplicate e correzioni successive. Il calcolo, 60 meno 40, dimostra una differenza di 20 ore. Non ne spiega ancora l’origine e non dimostra una perdita economica.

2. Assegnare un compito preciso a ogni fonte

Il contratto stabilisce l’accordo. La conversazione permette di ricostruire la richiesta aggiuntiva. I dati aziendali mostrano il lavoro svolto e le informazioni di fatturazione.

• Contratto: il perimetro accettato e le 40 ore incluse, con versione e sezione pertinente.
• Slack: la richiesta di redesign, la data, le persone coinvolte e gli scambi su perimetro o prezzo.
• Dati aziendali: le 60 ore registrate, le 20 ore di redesign e le informazioni sulla relativa fatturazione.

Una richiesta su Slack, da sola, non prova che sia stata approvata una modifica a pagamento. Se manca l’approvazione o la prova della fatturazione, mantenere visibile l’incertezza anziché sostituirla con una supposizione.

3. Far controllare la spiegazione a chi conosce i fatti

In questo esempio Alex controlla le ore e conferma che il redesign aggiuntivo non è stato fatturato. Sam consulta il contratto e conferma che il lavoro era fuori dal perimetro concordato. Ognuno conferma la parte che può verificare.

Conservare i riferimenti insieme alle conferme. Se Sam non concorda sull’interpretazione del perimetro, registrare il disaccordo e il prossimo controllo necessario. Una frase sicura non deve nascondere una questione ancora aperta.

4. Salvare una spiegazione utile alla prossima decisione

La risposta può essere breve: «Atlas ha utilizzato 60 ore rispetto alle 40 incluse nel contratto a prezzo fisso. Le 20 ore aggiuntive riguardavano un redesign fuori perimetro e non sono state fatturate». Allegare la sezione del contratto, la richiesta Slack, le registrazioni del lavoro, i nomi e la data di conferma.

Maya può usare questo contesto per preparare il rinnovo. Aiuta a discutere perimetro, approvazioni e prezzo futuro. Non indica quale prezzo applicare né se il cliente sia redditizio senza i dati finanziari necessari.

5. Ricontrollare prima di riutilizzare

Prima di riprendere la risposta, verificare che riguardi ancora lo stesso progetto e periodo. Un nuovo contratto, una registrazione corretta o una fattura successiva possono cambiarla. Contano anche i permessi: trovare una risposta confermata non deve esporre dati che il lettore non è autorizzato a consultare.

Il metodo della scheda di risposta confermata aiuta a conservare questo contesto. QAIZEN sta sviluppando un assistente di conoscenza IA per questo percorso: trovare informazioni tra documenti, conversazioni e strumenti aziendali e riutilizzare risposte verificate dal team. Il metodo descritto si può già applicare ai dati che il team gestisce oggi.