La complessità dei progetti

Asse verticale per Agreement/Disagreement: si intende il grado di accordo sui requisiti di progetto, o in altri termini “quanto gli stakeholder conoscono ciò che vogliono”; possiamo quindi sintetizzare questa dimensione con WHAT TO BE DONE. I punti dell’asse più verso l’origine (Agreement), indicano le situazioni in cui gli stakeholder sono in grado di descrivere i loro bisogni, e nella loro mente c’è già un’idea piuttosto chiara di COSA vorrebbero ricevere dal progetto (es. il leone vede chiaramente COSA potrebbe soddisfare il suo bisogno di fame, cioè la gazzella), Ma, per contro, i punti più lontani dall’origine (Disagreement), diversamente da prima, indicano le situazioni in cui gli stakeholder, seppur in grado di descrivere i loro bisogni, NON hanno idea del COSA vorrebbero che il progetto stesso rilasciasse (es. la gazzella sa bene che deve salvarsi la vita, ma non conosce quale sia la destinazione finale che deve raggiungere).

Asse orizzontale per Certainty/Uncertainty: ci si riferisce alla connessione causa-effetto, o in altri termini,  “come il team può soddisfare le necessità espresse”; possiamo sintetizzare questa dimensione con il HOW WE WILL DEVELOP IT. I punti dell’asse più verso l’origine (Certainty), indicano quelle situazioni tipiche dove  sia la soluzione e sia la tecnologia per soddisfare le necessità degli stakeholder, sono note, per di più anche già usate varie volte in passato (es. il leone attua in modo ripetitivo il suo meccanismo per procacciarsi le prede; quando caccia, è usuale che si apposti, osservi e si sposti per analizzare le informazioni a sua disposizione; dopo una lunga pianificazione, scatena la corsa verso la gazzella che aveva adocchiato e studiato).

Proseguendo, per contro, i punti più lontani dall’origine (Uncertainty), indicano le situazioni in cui si deve obbligatoriamente far ricorso ad una forte sperimentazione (nulla di già noto), in modo da comprendere rapidamente COME realizzare il lavoro (es. la gazzella inizia subito ad andare verso le montagne, ma in tempi rapidissimi deve altrettanto verificare se la direzione è quella giusta, sempre in funzione sia della posizione del leone che del contesto orografico, man mano che corre).

A questo punto, avendo compreso i 2 assi di riferimento, possiamo ora intercettare delle aree in cui il nostro progetto potrebbe ricadere.

• Area A: in questa area ricadono tutte quelle attività che oggi vengono genericamente chiamate Business As Usual (BAU); cioè, non si tratta di progetti, ma di attività ricorsive svolte molte volte. Non siamo di fronte ad un progetto, ma davanti ad attività ongoing, cioè continuative, che sorreggono un business lanciato da un progetto ormai concluso.
• Area B: Stacey, chiama quest’area “la zona della complicazione”, poiché qui rientrano tutti quei progetti di tipo predictive (o traditional se si preferisce) in cui si creano specifici piani per ottenere i risultati attesi; risultati che vengono costantemente monitorati e confrontati con i suddetti piani, in maniera da comprendere chiaramente e tempestivamente se occorre correggere qualcosa, qualora ci si stia discostando dagli stessi. In quest’area si evidenziano prettamente due situazioni limite:
  • Media Certainty e Disagreement – qui è utile che il project management si focalizzi molto sull’area Risk management;
  • Certainty e medio Agreement – qui è utile che il project management si focalizzi molto sull’area Stakeholder management.
• Area C: Stacey chiama questa grande area centrale “la zona della complessità”, dove gli approcci gestionali tradizionali non sono molto efficaci; qui deve prevalere la creatività e l’innovazione, si deve rompere con il passato per creare nuove modalità operative. Questa è l’area della sperimentazione, in cui i metodi Agile possono rappresentare una soluzione gestionale utile per guidare il progetto.
• Area D: quest’area è la zona del caos. Queste situazioni, con alti livelli di incertezza e disaccordo, spesso sfociano in anarchia; in questi contesti i metodi tradizionali di project management sono insufficienti e l’Agile purtroppo non sembra essere efficace. Se ci si trova in quest’area, si può comunque adottare una strategia spesso condivisa da molti esperti, ovvero, si deve semplicemente evitare di affrontare immediatamente questi contesti, occorre “prendere tempo” per ricercare maggiori informazioni in merito. Sebbene questa strategia possa essere protettiva nel breve periodo, risulta purtroppo disastrosa se impegnata a lungo; in altre parole, ci si deve concedere del tempo per chiarire il progetto, ma non troppo, perlomeno non tanto da indurre gli stakeholder a dar per scontato che il progetto, nonostante tutto, si stia realizzando.