Nonostante il periodo estivo il team di sviluppo di Twproject non si è certo fermato ed oggi rilasciamo una nuova versione che siamo certi apprezzerete molto. Questo nuovo rilascio, gratuito per tutti i clienti, include un’importante novità sul carico di lavoro ed in particolare sull’uso del dipartimento sui progetti, ma vediamo tutti i particolari.

In Twproject è sempre stato possibile assegnare un dipartimento su un progetto, ma l’assegnazione aveva la sola funzione di dare, a tutti coloro che vi appartenevano, specifici permessi sul progetto stesso.

Da oggi, questa assegnazione avrà un valore ancora maggiore.

Ma questa release non include solo questa importante modifica, abbiamo infatti anche potenziato notevolmente la gestione finanziaria di Twproject, rendendola più adatta a realtà aziendali fortemente strutturate.

Inoltre sono inclusi numerosi bug-fix, di cui puoi trovare un elenco completo alla pagina del changelog.

Questo aggiornamento è gratuito per tutti gli utenti di Twproject ed include aggiornamenti al database. È consigliato quindi un backup completo dell’applicazione prima di effettuare l’upgrade.

Vediamo adesso le novità in dettaglio.

Nuove funzionalità

Assegnazioni di dipartimento

Questa nuova importante modifica comporta diversi migliorie.

Come abbiamo già detto l’assegnazione di un dipartimento al progetto è sempre stato possibile, ma la funzione era solo quella di concedere i permessi alle persone che facevano parte del dipartimento/reparto (i permessi sono quelli dati dal ruolo con cui è assegnato il dipartimento).

Le risorse non potevano registrare ore lavorate sul dipartimento, ma richiedevano un propria assegnazione.

Da oggi questo sarà possibile! Appartenere ad un dipartimento assegnato su un progetto vi darà la possibilità di rendicontare direttamente su questa assegnazione, potrete vedere il progetto e lavorare con i ToDo.

Questa grande modifica vi permetterà di poter assegnare un dipartimento senza preoccuparvi di chi si occuperà delle attività nello specifico sapendo che tutti coloro che vi appartengo sono su di esso completamente operativi.

In ambienti di lavoro in cui ci sono team di grandi dimensioni e in cui si tenda a lavorare in modalità agile, risulterà molto comodo avere una sola assegnazione sui cui tutti rendicontano.

Anche l’assegnazione di un ToDo ad una persona non creerà più un’assegnazione alla persona se quella persona fa parte di un reparto/team già assegnato sul progetto.

Nelle interfacce di analisi del worklog comunque è mostrato il dettaglio delle persone che hanno rendicontato sull’assegnazione di dipartimento, restando immutate tutte le procedure di analisi, controllo ed approvazione.

Si tratta di un nuovo comportamento di default di Twproject e non ha quindi bisogno di essere attivato.

Di conseguenza in tutte le interfacce in cui sono mostrate le proprie assegnazioni o in cui è possibile registrare i propri worklog, oltre alle assegnazioni personali, sono mostrate anche quelle del reparto di diretta appartenenza, con la possibilità di rendicontare su di esse.

Qualora invece una persona abbia sulla stessa fase anche un propria assegnazione nominale, quella di reparto viene ignorata e mostrata solo quella personale.

Carico di lavoro del dipartimento

Ovviamente questa modifica, che da al dipartimento un’importanza ancora maggiore rispetto a quella avuto finora, non poteva rimanere incompleta e per questo è stato aggiunto anche il calcolo del carico ottimizzato sul dipartimento nel suo complesso.

Finora era possibile visualizzare solo il carico di lavoro delle persone; con questa versione diventa possibile anche per i dipartimenti.

Il calcolo del carico di lavoro considera molti parametri quali le date, lo stato e la tipologia dei progetti, la stima delle assegnazioni, le ore pianificate attraverso il piano e/o i ToDo, le ore effettivamente lavorabili al netto di permessi/ferie/malattie, le ore già lavorate su ogni singola assegnazione, per ogni persona che appartiene al dipartimento. Una volta estratti questi dati l’algoritmo cerca di ottimizzare l’allocazione delle risorse in modo da ottenere un carico il più verosimile possibile, sulla base dei dati di cui si è a disposizione:

Ore lavorate dalla risorsa (sia persona che dipartimento)
Capacità lavorativa per quel giorno. È la somma delle capacità di tutte le risorse che appartengono al dipartimento; tiene conto dell’orario lavorativo (part time orizzontali o verticali) e può quindi essere diversa di giorno in giorno.
Carico complessivo calcolato come somma di tutti i contributi.

I colori sono assegnati sulla base della fase/progetto. Se più risorse sono assegnate alla stessa fase/progetto il box rappresenta il totale di tutti i contributi.

Le indisponibilità, riportate in fondo alla barra in colore rosa pallido, sono ferie, permessi, etc., inserite nell’agenda di Twproject indicandone la tipologia.

Per maggiori dettagli sull’algoritmo implementato da Twproject per tale calcolo, ti consigliamo la lettura di questo post relativo al carico di lavoro delle risorse.

Gestione potenziata dei costi

Veniamo adesso alla parte relativa al potenziamento dei costi.

Budget di progetto

Sono state inserite diverse configurazioni attivabili, a spente di default che vi permettono un maggiore controllo su budget e stime.

L’attivazione del parametro BUDGET_OVERFLOW_FORBIDDEN fa sì che l’applicazione impedisca l’inserimento di costi finanziari, o derivanti dalle risorse assegnate, se questi superano il budget assegnato. Inoltre la somma del budget distribuito sulle fasi deve rispettare quello definito sul livello superiore.

Questo comportamento ha lo scopo di facilitare l’attività di pianificazione finanziaria del project manager, che viene quindi guidato da Twproject nell’inserimento di stime consistenti con il budget disponibile per ogni singola fase di progetto.

Se analizziamo quindi in dettaglio il controllo esercitato dal budget, vediamo che:

ogni sotto-fase non può avere un budget superiore a quello della fase cui appartiene (overflow) e, allo stesso modo, il budget di un nodo padre non può essere inferiore alla somma dei budget delle proprie sotto-fasi (underflow).

i costi stimati di una fase non potranno essere superiori al budget della fase relativa così come i costi derivanti dal lavoro delle risorse assegnate (costo orario della risorsa moltiplicato per le ore di lavoro stimate sulla sua assegnazione).

i costi reali, a loro volta, sono sottoposti al controllo dei costi stimati cui devono necessariamente riferirsi e che non possono di fatto superare.

le spese personali sono vincolate al proprio budget personale il quale contribuisce a sua volta ad erodere il budget della fase.

Per meglio orientarsi nella gestione finanziaria, Twproject mostra per ogni nodo il budget destinato a tutte le sue eventuali sotto-fasi, oltre al residuo ancora utilizzabile (valore dato dal budget sulla fase cui vengono sottratti quanto assegnato alle sotto-fasi ed i costi della fase stessa).

Come accennato, per simmetria con l’overflow, si controlla anche l’underflow, per cui non è permesso modificare un budget già inserito al di sotto di quanto già distribuito o stimato e, allo stesso modo, non è possibile abbassare un costo stimato al di sotto del reale già sostenuto.

Sono stati creati due nuovi permessi per la gestione del budget.

Gestione del costo orario delle risorse USE_REAL_RESOURCE_COST

Twproject ha due indicazioni del costo orario: una sulla risorsa, l’altra sull’assegnazione.

Questo per poter differenziare il costo dei propri dipendenti per l’azienda (costo sulla risorsa) dal valore con cui la risorsa stessa è “venduta” ad un cliente (costo sull’assegnazione).

Nel caso però fosse necessario o più comodo utilizzare sempre il costo della risorsa, è stato introdotto questo nuovo flag, la cui attivazione disabilita il costo orario sull’assegnazione che viene quindi ignorato.

Come conseguenza, un eventuale cambio del costo orario sulla risorsa sarà propagato immediatamente a tutte le assegnazioni dei task aventi stato attivo o in attesa. Viene anche attivata la visualizzazione dei costi di consuntivazione (worklog) storicizzati e delle stime, attualizzate sul nuovo costo.

Il costo di worklog storicizzato (costo reale) è dato dalla somma dei costi dei singoli worklog al costo orario della risorsa alla data di inserimento, mentre il costo stimato è dato dal costo orario storicizzato, su quanto effettivamente registrato, e dal costo corrente per la parte restante:

costo reale worklog + (ore stimate – ore fatte) * costo orario attuale

Da notare che in caso di cambio del costo orario di una risorsa la pagina dei costi del progetto andrà interpretata tenendo conto del calcolo sopra indicato, non semplicemente facendo la moltiplicazione del costo orario x le ore.

Gestione delle consuntivazioni (inserimento worklog)
WORKLOG_OVERFLOW_FORBIDDEN

Collegata alla gestione del budget di progetto, ma indipendente da esso, è il blocco della registrazione dei worklog in caso di sforamento delle ore previste.

Una volta attivata questa proprietà, non sarà più possibile inserire ore in eccedenza rispetto alla stima; quindi, in caso di ore non stimate, l’inserimento di worklog viene disabilitato.

Nel caso di assegnazione a dipartimento (vedi paragrafo successivo) il blocco è attivato sul totale di ore inserite da tutto il team.

In caso di sforamento, un alert avverte dell’errore e mostra il numero residuo di ore inseribili.

Si noti che questo blocco non prende in considerazione lo sforamento del budget previsto (sempre che la funzionalità sia attiva), ma la sola stima sull’assegnazione; questo per non bloccare le normali attività lavorative in caso di cambi di costo orario delle risorse.

La proprietà WORKLOG_ROUNDING_TO controlla invece l’arrotondamento della consuntivazione a ‘n’ minuti prestabiliti. Il valore 0 (default) non arrotonda e quindi disattiva la proprietà.

Gestione dei centri di costo

Sempre in ottica di semplificare la gestione di grandi team e progetti complessi sono state introdotte diverse novità relative ai centri di costo.

Propagazione centri di costo

Un nuovo comportamento di default, fa sì che quando viene cambiato il centro di costo su un task o risorsa, tutti i “figli” aventi il vecchio centro di costo sono aggiornati al nuovo. Se però un figlio ne aveva uno diverso, questo non viene modificato.

Scelta tipologia centro di costo
USE_DISTINCT_COSTCENTER_PRJ_RES

La sua attivazione comporta la comparsa nell’editor del centro di costo di un nuovo menù a tendina, la “tipologia”, avente due soli valori, progetto e risorsa, ed i drop-down di task e risorsa mostreranno solo i rispettivi centri di costo.

Ereditarietà del centro di costo
COSTS_INHERIT_COST_CENTER

Questa nuova custom feature è stata introdotta per far si che i costi aggiuntivi di progetto ereditino il centro di costo dalla fase, senza possibilità di modifica.

Sicurezza

Con questo rilascio abbiamo introdotto 5 nuovi permessi relativi alla gestione sulle fasi/progetti del budget, dei ricavi e del centro di costo.

La procedura di aggiornamento dell’applicazione li aggiunge automaticamente a tutti i ruoli esistenti che abbiano però i permessi analoghi sui costi.

Per aumentare la sicurezza, la ownership delle fasi di progetto verrà automaticamente ereditata dal nodo padre.

In questo modo, se anche la singola fase di progetto avrà un responsabile diverso (ad es. un project manager junior) rispetto al progetto principale, tale responsabile non acquisirà di default la ownership su tutti gli aspetti della fase, come i costi, ecc.

Molte altre novità

Kanban: aggiunta la ricerca in ogni colonna.

Lista assegnazioni: la stampa include ora anche tutti gli eventuali campi personalizzati.

Carico operatori: nel popup di dettaglio abbiamo aumentato e migliorato le informazioni di riepilogo.

Task aventi stato indefinito: la loro percentuale di avanzamento è sempre azzerata e non vengono presi in considerazione nel calcolo di avanzamento del progetto.

Ma tutto questo non è che un breve estratto di quanto puoi trovare in Twproject 7.1.007!

Con questa release Twproject ha approntato davvero tante altre migliorie al sistema e bug-fix, di cui puoi trovare un elenco completo alla pagina del changelog.

Dopo mesi di studio e implementazione siamo davvero felici di annunciare che è stata rilasciata una nuova versione di Twproject che include, tra le varie ottimizzazioni, un particolare passo in avanti sull’utilizzo del diagramma di Gantt.

Il Gantt sviluppato da Twproject è indubbiamente uno dei migliori sul mercato attuale in quanto a flessibilità e interazione con le altre pagine dell’applicazione.

È inoltre uno dei pochi che permette di fare ogni sorta di test sulla durata e dipendenza delle fasi dei progetti e salvare le modifiche apportate solo in un secondo momento, rivelandosi dunque uno strumento utile non solo durante la condivisione delle tempistiche ma anche in fase di studio delle stesse.

Come sempre la nuova release sarà a beneficio immediato di tutti i nostri clienti che potranno iniziare a utilizzare le nuove funzionalità da subito!

Le dipendenze nel Gantt

Secondo definizione, nell’ambito del project management si intende per “dipendenza” la relazione che intercorre tra due attività di un progetto o tra un’attività e una milestone (un punto preciso che definisce l’inizio o la fine di una fase rilevante).

Le dipendenze permettono dunque di collegare una fase alla successiva in modo da indicare che esse sono consequenziali.

Introduzione di nuove tipologie

Fino ad ora in Twproject, le dipendenze tra le fasi di progetto che l’utente poteva inserire erano di un’unica tipologia, la cosiddetta classica Finish to start (FS). Ciò significa che l’attività A deve finire prima che l’attività B cominci, o in altre parole che l’attività B non può iniziare prima che A sia conclusa.

Ma approfondendo questa tematica e anche grazie al feedback dei nostri clienti, ci siamo resi conto che limitare le possibili relazioni esistenti tra le fasi di un progetto a questa classica tipologia di dipendenza era riduttivo. Esistono infatti ulteriori relazioni che possono svilupparsi tra le attività da svolgere e che sono state teorizzate nei principi del project management. Vediamole nel dettaglio:

La tipologia di relazione Finish to finish (FF) implica che l’attività B non possa finire prima che sia finita anche A. Se ad esempio l’attività B il completamento della scrittura di un libro e l’attività A è la stesura dell’ultimo capitolo, risulta chiaro che A deve necessariamente finire perché anche B possa dirsi conclusa.

Ancora, si dà il caso che una certa attività non possa iniziare prima che un’altra attività sia a sua volta iniziata, e in questo caso la relazione sarà di tipo Start to start (SS). Un classico esempio è l’attività di project management (B) di un progetto che non può cominciare prima dell’inizio del progetto stesso (A).

Infine, un caso molto specifico è rappresentato dall’ultima tipologia di relazione chiamata Start to finish (SF) che è probabilmente la più complessa da comprendere e che si applica solo in determinati contesti. In questo caso l’attività A deve iniziare prima che B finisca, o in altri termini B non può finire finche A non sarà iniziata. Un simile scenario può presentarsi ad esempio in fase di cambio turno in un impianto di produzione i cui macchinari hanno bisogno di costante monitoraggio. Il turno iniziale (A) non potrà dirsi concluso se non sarà già iniziato il turno successivo (B) pena la messa a rischio dell’impianto.

Siamo quindi felicissimi di annunciare che nella nuova release di Twproject abbiamo introdotto la possibilità di assegnare alle fasi di progetto tutte suddette tipologie di dipendenze.

Dopo aver creato la dipendenza tra due fasi, potrai eventualmente modificare il valore di default rappresentato dalla dipendenza FS e selezionare un altro tipo di relazione.

L’applicazione del concetto di “elasticità”

Un altro importante cambio di paradigma, che ci rende molto fieri del nostro lavoro, è rappresentato dall’aver reso “elastiche” tutte le nuove dipendenze aggiunte.

Se infatti fino ad oggi l’assegnazione di una dipendenza sanciva il susseguirsi lineare di un’attività dopo l’altra, sappiamo bene che nel mondo reale non sempre le fasi si avvicendano in successione, senza sovrapposizioni o tempi vacanti.

È per questo che noi di Twproject abbiamo deciso di permettere all’utente di gestire liberamente questa elasticità.

Da ora dunque quando si inserisce una dipendenza questa sarà salvata in un primo momento con la tipologia FS hard di default. Ma questa classica dipendenza “rigida” potrà essere convertita in “elastica” e con qualsiasi tipo di relazione.

Ciò significa che due attività interdipendenti possono anche non essere cronologicamente conseguenti e allontanarsi lasciando eventuali spazi vuoti tra esse, o sovrapporsi per un certo periodo, purché venga rispettata la logica della dipendenza scelta.

Questo rappresenta una grossa novità in termini di aderenza alla realtà dei fatti quando si porta avanti un progetto concreto e rafforza il concetto di delega che in Twproject è centrale.

Questa elasticità infatti introduce maggiore flessibilità nell’azione sulle date di fine delle fasi di progetto che non necessariamente comportano uno slittamento delle fasi conseguenti.

Immaginate un’albero di progetto in cui è assegnato un Project Manager (PM) per l’intero progetto e poi uno specifico per ogni fase, uno per la fase di analisi(PMA), progettazione(PMG) e produzione(PMD), queste fasi sono legate da una dipendenza FS (Finish to Start).

Il PM può definire una durata totale di progetto e assegnare alle fasi una durata specifica, grazie alle dipendenze elastiche, può, seppur mantenendo la logica delle dipendenze, creare un lag tra le fasi e lasciare quindi ai pm di fase PMA, PMG e PMD maggiore liberta di azione (spostamento data fine e inizio) senza interferire sulle date complessive!

Questo non era possibile prima, poichè uno spostamento di una data fine, per esempio della fase di analisi, avrebbe necessariamente comportato uno slittamento delle fasi conseguenti, fasi su cui PMA non ha nessun diritto.

Altre novità

Ma non finisce qui. Con questa release Twproject ha approntato davvero tante migliorie al sistema, di cui puoi trovare un elenco completo alla pagina del changelog.

Eccone un assaggio:

Revenues: è stato introdotto un utile strumento per trasformare in ricavo effettivo un valore stimato, in modo da facilitare ulteriormente l’inserimento di queste voci.

Worklog: sono stati stati aggiunti i filtri per ToDo e per progetto nel foglio di analisi dei worklog e inoltre sul timesheet è stata aggiunta un colonna con la somma dei worklog totali su una fase o progetto.

Sicurezza dei ruoli: abbiamo reso ancora più sicuri i permessi sulla gestione dei task in relazione all’inserimento dei costi e dei form.

Agenda: varie migliorie hanno riguardato l’agenda, tra cui la possibilità di visualizzare la durata dei ToDo, e inoltre gli eventi inseriti in agenda sono stati integrati in una riga dedicata sul planner dei ToDo e delle risorse.

Dunque, non perder tempo e vai subito a scoprire quanto queste ultime innovazioni di Twproject potranno giovare all’efficienza del tuo lavoro!

Tutti i clienti che utilizzano Twproject in cloud avranno l’aggiornamento in automatico nei prossimi giorni, mentre coloro che hanno Twproject installato sui propri server posso trovare i nuovi installer qui.

Tag: nuova release

New Twproject Release – Assegnazioni e carico per dipartimento

Nuove funzionalità

Assegnazioni di dipartimento

Carico di lavoro del dipartimento