Rispettare il budget di un cliente viene spesso frainteso come un esercizio di limitazione del cambiamento, quando in realtà si tratta di comprenderlo e controllarlo correttamente man mano che il progetto si evolve.
La maggior parte delle richieste relative al software inizia nello stesso punto. Un'organizzazione dispone di un processo esistente, spesso qualcosa che si è sviluppato nel tempo, e vuole trasformarlo in un'applicazione utilizzabile che migliori l'efficienza, la visibilità e il controllo.
A prima vista, sembra semplice. Il processo esiste già, quindi si presume che possa semplicemente essere tradotto in software. In molti casi, è vero. Se l'azienda comprende il processo e può documentarlo chiaramente, si è già alla linea di partenza.
Dal punto di vista della leadership, dovrebbe sembrare una posizione di controllo. L'organizzazione sa cosa fa, come opera e cosa ha bisogno che il sistema supporti.
La sfida inizia quando quel processo comincia a prendere forma all'interno di un sistema.
Non appena diventa visibile, le persone iniziano a vederlo in modo diverso. Si coinvolgono, vedono come può evolversi e iniziano a riconoscere nuove opportunità. Emergono nuove idee, vengono identificati casi limite, e diversi stakeholder interpretano come dovrebbe funzionare in modi leggermente diversi. Questo non è un fallimento, è una parte naturale del rendere esplicito un processo.
A questo punto, anche i cambiamenti apparentemente semplici devono essere esaminati da ogni prospettiva e in ogni fase del processo. Ciò che appare minore in isolamento può avere implicazioni più ampie, in particolare quando sono coinvolti più ruoli, decisioni e dipendenze.
In una consegna software ben strutturata, il focus è su ciò che conta di più per l'organizzazione, non solo su ciò che viene richiesto dagli stakeholder. In molti casi, ciò include la verificabilità, che è fondamentale per l'organizzazione ma spesso trascurata a favore di funzionalità aggiuntive.
Gli stakeholder si concentrano naturalmente su ciò che vogliono che il sistema faccia. Raramente si concentrano su come tali cambiamenti devono essere implementati, registrati e governati una volta che il sistema è in operazione.
Questo cambia la natura anche della richiesta più semplice. Un piccolo aggiustamento non è più solo un cambiamento tecnico, diventa parte di un processo controllato e tracciabile. Di conseguenza, ciò che appare minore può avere un impatto molto maggiore una volta considerati conformità, responsabilità e visibilità operativa.
Se il cambiamento non è controllato, non lo è nemmeno il risultato.
Ciò che inizia come un'iniziativa ben definita può diventare rapidamente qualcosa di completamente diverso, non per cattive intenzioni, ma per mancanza di struttura attorno a come vengono prese le decisioni mentre il sistema si evolve. Il costo non è solo finanziario. Si misura in tempo, complessità, interruzioni operative e perdita di chiarezza.
È qui che molte organizzazioni perdono il controllo senza rendersene conto.
Credono di gestire la consegna, quando in realtà la direzione del sistema viene modellata in modo incrementale da cambiamenti non misurati.
È esattamente qui che opera Libertas Software Research.
Non semplicemente nella costruzione di sistemi, ma nel garantire che tali sistemi rimangano allineati con l'organizzazione mentre si evolvono. Ciò significa creare struttura attorno al cambiamento, renderne visibile l'impatto e garantire che ogni decisione sia compresa nel contesto di costi, tempi e operatività a lungo termine.
La domanda non è se il cambiamento accadrà.
Accadrà.
La domanda è chi lo controlla.