Torno a parlare dell’argomento gestione della progettazione nelle aziende.
Di solito, come viene gestita praticamente la progettazione nelle organizzazioni tradizionali?
Il ciclo solitamente è qualcosa di questo tipo:
- si definisce il progetto
- si costruisce il diagramma di Gantt che descrive le fasi principali, le risorse e le percentuali di compimento delle varie fasi
- finite le varie fasi il progetto viene chiuso.
Io oggi voglio parlarvi di quelle percentuali di compimento delle varie attività specificate nel diagramma di Gantt.
Quando determiniamo una attività nel diagramma di Gantt, di solito diciamo che, quando questa attività è compiuta al 50% il diagramma deve riportare questa percentuale. Se al 70% idem ecc. Di solito quando siamo quasi al termine del tempo pianificato per una fase diciamo che l’attività è fatta al 95% anche se sappiamo benissimo che spesso siamo in ritardo, ma per non fare brutta figura con i nostri capi, questo ed altro… Poi si scopre lo stesso quello che si è fatto e si corre per recuperare ma a quel punto è già troppo tardi…
Quello che propongo io è la seguente cosa: perché non perdiamo un pò più di tempo nella pianificazione del progetto e determiniamo, anziché attività generiche, delle attività dettagliate da compiere per far avanzare il progetto? E non andiamo a definire la percentuale di compimento come parametro di monitoraggio ma che queste attività abbiano solo due stati: Sì o No, Fatto o Non fatto, 0% o 100% – attività booleane, senza stati intermedi.
Questa attività di pianificazione deve essere fatta dal responsabile di ogni fase specifica del progetto che, in aggiunta al progetto originale, magari scritto in termini generici, si sviluppa una propria checklist con queste attività dettagliate, con possibile risposta booleana. In questo modo sa esattamente dove si trova, cosa ha fatto e cosa ha ancora da fare, si gestisce il suo flusso delle attività del progetto.
Cosa ne dite di questa mia proposta? Vi piace come impostazione oppure avete qualche idea diversa?
Caro Dragan, secondo me (sai che provoco! 😉 ) parti da presupposti sbagliati.
Se io devo dire al mio capo (non mi piace \capo\) che sono al 95 quando invece so che sono al 70 o 60 o 99, sto tradendo la sua fiducia, ma peggio, la mia in me stesso! I miei valori (onestà, trasparenza, …) mi obbligano a dire al momento in cui so che sto andando fuori pianificazione: \hey, stop un attimo! Sto andando fuori pianificazione! Ripianifichiamo!\ Progettare per definizione è \stimare\ obiettivi (tempi, finanze, risorse umane, tecnologiche ecc.).
Sbagliare deve essere considerato.
Semmai, invece di investire prezioso tempo in dettagli che nemmeno la migliore analisi dei rischi mi può definire con una buona certezza/certitudine, mettiamo delle belle buone sante milestone di riesame, come ogni corso di project management ti insegna a fare. Lì vediamo se siamo in tempo e solo se no, se necessario, andiamo a incerottarci.
OK?
Lo sai che anch’io provoco con i miei post. Anche per me l’onestà e trasparenza è alla base di tutto.
Ma quando pianifico un progetto mi piace sapere quando ho raggiunto un milestone in maniera inequivocabile, con una condizione ben definita dall’inizio e chiara a tutti. Questo per me è la situazione booleana – fatto/non fatto.
Ripianificare non mi piace. E’ uno spreco di tempo. Preferisco definire una condizione (anziché dettagliare le finanze, le risorse, i tempi al minuto) nella quale voglio vedere il mio processo/prodotto dopo un tot di tempo. E risolvere i problemi che trovo sul percorso per raggiungere questa condizione. Lavorando con le persone nella mia squadra e apprendendo le difficoltà insieme a loro. Ma tutto entro il tempo stabilito. Ma nel inseguire questa condizione devo attenermi a qualche standard, valutare tutte le possibili alternative con SBCE e questo mi viene dato dalle curve di compromesso che avevo discusso qualche giorno fa.
Può sembrare che una progettazione fatta definendo il prodotto dall’inizio può essere migliore, ma non considerando le varie alternative si possono perdere occasioni che non si pensava neanche esistessero prima di individuarle. Ed avendo considerato le varie alternative si scopre anche quali possono essere tutti i vari problemi di qualità, si eliminano alla fonte e quindi tutto il ciclo dura meno in quanto non ci sono riparazioni dell’ultima ora come sempre succede nella progettazione tradizionale.
Carissimo, io ho fatto esperienze del mondo reale, dure, pesanti, dove progettare non era inteso come un “save as” di qualcosa di ben conosciuto, ma era andare a creare qualcosa di innovativo, di nuovo.
Sfido chiunque a pianificare un gantt che tiene conto di fattori che anche con il miglior RM (mi ripeto) non puoi prevedere.
Forse ero troppo ai limiti della progettazione, molto più sulla ricerca precompetitiva, nei casi che mi hanno cresciuto…
Oppure non mi resta che dover ammettere che ero un passimo capo progetto 🙁
Di solito, se non hai conoscenze di prodotto/prototipo che stai costruendo, il primo ciclo ti serve come raccoglitore di esperienza e di dati per i cicli successivi… Non puoi aspettarti molto senza i dati. Quindi non credo che si tratta di cattiva conduzione del progetto.
Anch’io mi sono trovato coinvolto in molti progetti dove dal passato non avevo nessun dato. E ho condotto male il progetto. Sbagliando, andando in direzione errata, provando le cose. Ma registrando gli errori per non commetterli le volte successive…
Noi abbiamo affrontato il problema con tutt’altro approccio,partendo dal basso e coinvolgendo direttamente tutti gli operatori interessati, con soluzioni aperte ( possiamo chiamarle innovative ? ,project è innovativo ? pe r me no) basate sulla comunicazione interattiva, offerte dalla rete
Cos’è la progettazione ? se non un insieme di relazioni,
tra il progettista e il cliente (logica LAC),
tra il proggetista e la sua mente,
tra il prodotto,
tra le norme e i vincoli costruttivi,
tra le persone dell’ufficio e i progettisti esterni, e fornitori esterni
tra i responsabili di reparto e la sala prove,
tra i disegni e le similitudini di prodotto , distinte, fascicolo tecnico e così via…
Cosìè al RETE se non un insieme di relazioni, usiamo gli stessi metodi nell’ufficio tecnico e vedremo i risultati per una Progettazioen LEAN o Booleana ( mi piace la definizione)
Noi abbiamo usato i Ticket del Crm per trasmettere le informazioni tra le persone e misurare i risultati;
Il data base dei sugarCrm permette di monitorare continuamente lo stato dei lavori, in modo assai semplice.
Il sisetma rientra anche nel piano di miglioramento del sistema qualità,apprezzato dallìente certificatore.
Ma a prescidere da questo è la qualità della progettazione che migliora,l’aziend ain questione produce rettifiche per alberi a gomito con luce di 12 metri e grado di precisione della lavorazione, tolleranza di 4 micro.
Con Wiki abbiamo condiviso le infromazioni, saltando tutte le attività a Non valore aggiunto( NVA)
L’argomento merita un approfondimento( prossimo articolo)
Secondo me avete ragione entrambi, ognuno per il proprio ambito.
Quando faccio della RICERCA non ho ben chiari, a volte, nemmeno gli obiettivi. So abbastanza bene da dove parto ma non so esattamente dove andro’ a finire. La pianificazione qui non puo’ essere certo granulare, ma si possono comunque inserire dei toll gate (passa – non passa) riferiti al raggiungimento di determinati livelli (per esempio il tempo, oppure la percentuale di budget economico consumata), che sono booleani per definizione. Una situazione simile al processo di sviluppo con le design review.
Nei progetti di SVILUPPO, invece, dove parto da una situazione conosciuta e ho degli obiettivi (in termini di prestazioni, tempi e costi, ad esempio) definiti, secondo me e’ sempre meglio perdere piu’ tempo nella pianificazione (vedi la P del ciclo PDCA) e identificare la maggiore granularita’ possibile per le attivita’, in modo da avere poi sempre la situazione sotto controllo (chi fa cosa, dove siamo arrivati, quanto ci manca, cosa esattamente ci sta bloccando, etc).
Per quanto riguarda la ripianificazione, pur ammettendo che e’ una attivita’ abbastanza comune (anch’io sono colpevole… lo ammetto!), devo dire che cerco sempre di evitarla se possibile. Ad esempio ricorrendo a forze esterne per le attivita’ a minore valore aggiunto, oppure ricorrendo allo straordinario, o allargando il team.
Qualche tempo fa parlavo proprio di questo argomento con John Drogosz, professore della Michigan State e co-autore di alcuni libri con John Shook, e lui sottolineava proprio questo aspetto (vedendolo come una abitudine italiana…): appena abbiamo un problema e ci rendiamo conto che non riusciamo a mantenere le date promesse, la prima cosa che facciamo e’ ripianificare. Buttiamo le mani avanti per poi non dover dire che siamo in ritardo. E lo spostamento delle date ha l’effetto deleterio di abbassare la tensione, e porta spesso ad ulteriori revisioni. E tutto questo e’ un vero e proprio spreco che si auto-alimenta!
Ernesto, abbiamo scritto il nostro commento quasi in contemporanea, e quindi non l’avevo ancora letto.
In questo periodo non mi occupo direttamente dello sviluppo tecnico, ma piu’ di produzione (=> fabbrica). Gestisco comunque anche alcune risorse dell’ufficio tecnico durante lo sviluppo di alcune commesse critiche (molto complesse oppure con penali molto alte), e mi era proprio venuta l’idea di utilizzare i principi del CRM (e Sugar in particolare, vista la sua maturita’) per il tracking di tutte le decisioni piccole e grandi relative al prodotto, e di tutte le modifiche fatte rispetto alla versione iniziale, oltre che per gestire e registrare tutte le interazioni con il cliente (visite, richieste di modifica, accettazioni parziali, etc). Pensavo pero’ di essere un po’ avanti, e magari di essere da solo a riuscire a vedere il nesso tra il ciclo di vita del prodotto e il ciclo di vita del cliente!
Sono contento di vedere che qualcuno ha messo in pratica questa idea: significa che e’ fattibile (cosa non propriamente ovvia)!
Ottimi i vostri contributi! Grazie. Una precisazione: per ripianificazione io intendo un riesame dove si mettono sul tavolo le carte (scoperte). Nell’esempio di Massimiliano leggo tra le righe che non si vuole ammettere l’errore ma si cercano diversivi o scuse e non mi piace la definizione dei professori “all’italiana” . Si ha il coraggio di decidere di abbandonare il progetto se una ripianificazione porterebbe a toppare in modo pesante sugli obiettivi iniziali.
Ma ci sono premesse e scelte preliminari:
Faccio ricerca di base o applicata oppure faccio sviluppo o semplicemente progetto su una commessa?
Progettare cercando una nuova ricombinazione di DNA per curare una malattia o progettare la linea di imbottigliamento di un farmaco già sviluppato è fatto in modo molto diverso.
Sviluppare il software di regolazione dei segnali del nuovo desmo per la moto-gp è da gestire diversamente che progettare un ponte sullo stretto.
Per tornare all’abitudine italiana… dissento… forse ho avuto fortuna, ma nei progetti che ho avuto la fortuna di curare con partner italiani (dal petrolchimico all’università, alla piccole aziende di carpenteria o impiantistica) ho sempre costatato grande competenza, dedizione e serietà… appena si notava un inizio di slittamento erano investite le dovute risorse per recuperare e quasi sempre è funzionato benissimo. (da dire che non ho mai lavorato in progetti istituzionali – a parte nei progetti di ricerca finanziata, dove il discorso si potrebbe ampliare).
🙂
Dario, scusa forse ho espresso i concetti in maniera un po’ rude.
Cerco di essere schematico.
– in ogni progetto che porto avanti la trasparenza deve essere massima, specialmente sui problemi (ritardi, errori, etc), perche’ bisogna intervenire subito. Non ci deve essere spazio per diversivi o scuse, perche’ non fanno altro che mascherare problemi che molto probabilmente diventeranno con il tempo piu’ grandi
– sono d’accordo con la distinzione tra ricerca di base e sviluppo, era esattamente quello che volevo dire io! 😉
– anch’io ho partecipato a vari progetti, sempre a livello industriale, e molto spesso (non sempre purtroppo) con persone molto competenti e attive. Il fatto e’ che a volte all’estero colgono (sbagliando, magari) un certo “lassismo latino”, ma poi magari sono i primi a fare queste cose.