Pirati buongiorno e benvenuti in questo nuovo viaggio di Pirati del Management.

Ieri ho rivisto The Founder, il film che racconta l’ascesa di Ray Kroc e la trasformazione di un piccolo ristorante californiano, gestito dai fratelli McDonald, in una delle catene più riconoscibili al mondo.

Ora, sarebbe fin troppo scontato portarvi come spunto l’ingegnerizzazione dei processi che ha reso McDonald’s quello che è oggi o parlarvi della standardizzazione ossessiva che ha reso una cucina una catena di montaggio perfettamente sincronizzata, il concetto rivoluzionario del “Speedee Service System” dove ogni movimento è calcolato al millisecondo. Certo, è affascinante vedere come i fratelli McDonald abbiano letteralmente ridisegnato una cucina con il metodo del “Speedee Service System” dove ogni movimento è calcolato al millisecondo, rendendola una perfetta catena di montaggio industriale. Ma di questo parleremo un’altra volta, quando affronteremo il tema dei processi e della scalabilità.

Oggi voglio sfruttare l’occasione per fare un breve ripasso, che non fa mai male, della differenza tra: Project e Operations.

Projects vs operations

Nel gergo del project management esistono due concetti che sembrano simili ma sono profondamente diversi nella loro natura e, soprattutto, nel modo in cui vanno gestiti.

Un project (progetto) è un’attività temporanea, con un inizio e una fine ben definiti, il cui scopo è creare un risultato, un prodotto o un servizio unico e irripetibile. Ogni progetto ha le sue specificità, le sue sfide e i suoi rischi.

Le operations, invece, sono delle attività continuative e ripetitive nel tempo che mantengono l’organizzazione in funzione giorno dopo giorno. Rappresentano la gestione operativa di tutti i giorni. In parole povere, spesso, rispondono alla domanda “In pratica cosa fai sul lavoro?”

Nel caso di McDondal’s: aprire una nuova sede, lanciare un nuovo hamburger o ripensare il menù sono dei progetti. Il servizio giornaliero: friggere le patatine, servire i clienti o pulire i tavoli sono delle operations.

Ogni nuova apertura di McDonald’s è un progetto.

Ogni apertura, quindi ogni progetto, ha ha un inizio preciso: la firma del contratto per l’immobile e una fine altrettanto chiara: il giorno dell’inaugurazione. Il risultato da consegnare è sempre lo stesso sulla carta: un McDonald’s funzionante e operativo. Ma il percorso per arrivarci non è mai identico.

• Un locale può essere troppo piccolo.
• Un mercato può reagire in modo inatteso.
• Possono esserci problemi di forniture, di personale e di normative locali.

Nel film vediamo spesso Ray Kroc e il suo team affrontare ostacoli diversi a ogni apertura. Ad esempio le normative cambiano da stato a stato, costringendo il team ad adattarsi ogni volta. A Phoenix i fornitori locali non capiscono e non accettano gli standard richiesti. A Minneapolis risultò difficile reclutare del personale disposto a rispettare un sistema di preparazione maniacalmente rigido.

Lo schema generale di McDonald’s è sempre lo stesso, eppure il contesto non lo è mai del tutto.

Questa è l’essenza del project management: gestire l’unicità dentro un framework ripetibile.

Una volta aperto il ristorante, il progetto finisce e iniziano le operations.

Il ristorante deve servire hamburger, patatine e milkshake con la stessa qualità, lo stesso tempo, lo stesso processo, giorno dopo giorno. La gestione quotidiana e si replica, città dopo città, stato dopo stato.

McDonald’s vive esattamente in questo equilibrio: progetti unici per creare qualcosa di nuovo, operations standardizzate per farlo funzionare sempre allo stesso modo.
Ed è proprio qui che sta la sua forza.

Perché è importante la distinzione tra project e operations

Sapete che non sono un grande fan della teoria fine a se stessa, ma se qualsiasi corso, libro o trattato di project management viene sempre martellata questa differenza, un motivo ci sarà.

Confondere i due approcci è pericoloso. Se gestisci un operations come se fosse un progetto, quindi qualcosa di nuovo e imprevedibile, non riuscirai mai ad ottimizzare quell’attività, finendo probabilmente per sprecare tempo e risorse. Al contrario, se gestisci un progetto, che per sua natura è qualcosa di unico e irripetibile, come se fosse un operations rischierai di soffocare l’innovazione e di non adattarti alle sfide impreviste che inevitabilmente emergeranno lungo il percorso.

Quando applichi delle logiche operative rigide a un progetto, tendi a:

• Sottovalutare l’incertezza intrinseca in qualcosa che stai facendo per la prima volta
• Penalizzare la sperimentazione e l’apprendimento iterativo, elementi essenziali in un progetto
• Creare aspettative irrealistiche di efficienza e prevedibilità che un progetto semplicemente non può garantire

In un operations, la qualità si ottiene attraverso la standardizzazione. Sai esattamente cosa aspettarti e puoi misurare le deviazioni dagli standard con precisione.

Al contrario, in un progetto la qualità si costruisce passo dopo passo: prototipi, feedback, aggiustamenti. Se pretendi di applicare questi cicli esplorativi a un operations consolidato, finirai per destabilizzare dei processi che già funzionano, introducendo delle variabilità dove invece ti servirebbe linearità.

Questa distinzione, nella vita aziendale, viene spesso ignorata. Vedo manager che gestiscono i progetti come se fossero delle routine (“abbiamo sempre fatto così”) e operations trattate come delle continue emergenze. Ma se tutto è urgente, allora nulla è urgente.

Forse il punto è fermarsi ogni tanto e chiedersi: questa cosa che sto facendo, oggi, è davvero un progetto… o dovrebbe già essere un’operazione?

Per oggi è tutto,

Buon vento e non ingozzatevi troppo di patatine.

Capitan Cristian