“Errare è umano, perserverare è diabolico”, così venni interrotto dall’indimenticabile e compianto Prof. Marco Somalvico, docente di Intelligenza Artificiale e mio relatore, durante la discussione della tesi di laurea al Politecnico di Milano. Era ancora il tempo delle lavagne luminose e dei lucidi, e per la seconda volta mi ero frapposto tra proiettore e schermo oscurando la visione agli astanti. Non erano trascorsi 5 minuti dalla prima osservazione e di nuovo ero ricaduto nel medesimo errore.

In qualità di technical project manager in LABVANTAGE, ogniqualvolta si tratta di iniziare un nuovo progetto mi viene naturale ricordare quell’episodio e ripercorrere i problemi incontrati nei progetti passati per cercare di non ripetere errori già commessi.

In questa serie di articoli vorrei esporvi il frutto di queste riflessioni e passare in rassegna i problemi più comuni che ostacolano il raggiungimento degli obiettivi di un progetto di implementazione LIMS, i motivi per cui si tende a ripeterli e come sia possibile ridurne l’impatto trasformandoli in opportunità. Sorprendentemente, ma forse non troppo, scopriremo che questi problemi sono quelli tipici trattati nella letteratura classica relativa al “project management”.

Iniziamo la descrizione dei problemi più comuni tenendo conto che  l’ordine seguito non è da intendersi come graduatoria di importanza: l’impatto di ciascuno problema deve essere infatti valutato nel contesto di ciascun progetto e avrà in generale un’importanza che varia con le condizioni al contorno.

1 – Requisiti incompleti o non ben definiti (scope creep)

Se in generale l’esigenza dello sponsor del progetto è dapprincipio riassumibile in un semplice “abbiamo bisogno di un sistema LIMS per i nostri laboratori”, tale esigenza deve essere tramutata in requisiti ben definiti e condivisi all’interno della organizzazione. Molte volte i requisiti sono troppo generici ed espressi ad alto livello, altre volte arrivano ad una livello di dettaglio cosi specifico che diviene difficile darne una risposta in termini di funzionalità fornite dal software. In tutti i casi la corretta identificazione ed enunciazione dei requisiti nonché la traduzione dei medesimi in specifiche funzionali strutturate e coerenti deve diventare in questa fase iniziale il tema centrale del progetto dato che può determinarne a posteriori il successo o il fallimento. Diventa quindi fondamentale pianificare e gestire questa fase nel modo migliore.

La domanda che mi pongo spesso è se gli URS devono essere la mera espressione dei requisiti utente o se devono in qualche modo riflettere le caratteristiche del sistema LIMS che si sta implementando. I puristi propenderebbero sicuramente per la prima ipotesi poiché i requisiti NON devono essere influenzati da come essi verranno poi realizzati.

L’esperienza però mi ha portato ad essere più pragmatico e pensare che è inutile rinchiudersi in una torre d’avorio quando si vuole implementare un sistema LIMS commerciale, sforzandosi di redigere requisiti che ignorino le funzionalità di un software che già presenta una serie di sue specificità.

L’approccio migliore sta probabilmente in un compromesso tra i due estremi: ossia di prevedere sempre all’inizio di ogni progetto una specifica fase di analisi dei requisiti rispetto alle caratteristiche del prodotto, ciò che solitamente si chiama “scoping phase”. Obiettivo di questa fase è proprio quella di valutare la copertura dei requisiti utente rispetto alle funzionalità offerte dal software derivandone la cosiddettà “gap analysis” che individui quali parti del sistema richiedano particolari configurazioni e/o personalizzazioni necessarie al soddisfacimento dei requisiti non coperti. Il tutto verrà registrato in un documento di requisiti e di relative specifiche funzionali che sarà il punto di partenza del progetto di implementazione vero e proprio.

E’ fondamentale in questa fase prevedere dei momenti di verifica della configurazione e funzionalità del sistema per confermare di essere allineati a quanto richiesto dagli utenti. Personalmente ho riscontrato che il formato dello “workshop” (seminari di breve durata ed estremamente focalizzati su pochi e importanti temi di interesse) è quello che consente di raggiungere il consenso tra le parti nella maniera più efficace.

Grande attenzione va anche posta al diverso codice di linguaggio e gergo usato dalle persone coinvolte nel progetto che molto spesso sono un mix di tecnici con esperienza di laboratorio e consulenti aventi prevalentemente background informatico, problema che è possibile mitigare attraverso sessioni specifiche dedicate alla spiegazione dei termini di base che ricorrerano nelle conversazioni tra le parti nonché attraverso l’accorgimento di  aggiungere ai documenti dettagliati glossari.

Infine è utile pianificare anche una o più fasi dedicate alla realizzazione di prototipi per condividere con il gruppo di lavoro le diverse opzioni implementative e scegliere quella su cui indirizzare lo sviluppo secondo le pratiche suggerite dalla cosiddetta metodologia AGILE.

La fase di analisi e discussione dei requisiti (scoping phase) e la relativa discussione del risultato (gap analysis) dovrebbe essere presente in tutti i progetti di implementazione LIMS, può essere più o meno esplicita ma deve essere formalmemte prevista. A volte si è portati a saltare questa fase: vuoi perché il Fornitore della soluzione pensa di poter guidare le scelte degli utenti in base alla propria esperienza, vuoi per esigenze legate alle risorse finanziarie e/o ai tempi di progetto. Altre volte tale fase non è praticabile per mancanza di un riferimento lato Cliente che abbia allo contempo le necessarie conoscenze tecniche, la visione strategica del progetto e la relativa responsabilità decisionale, cosa che  spesso costringe il Fornitore a farsi carico di decisioni che non gli spettano. In queste situazioni è bene che quanto meno lo sponsor del progetto lato Cliente e il responsabile di progetto lato Fornitore decidano di comune accordo come rispondere ai risultati emersi durante la scoping phase e documentati nella gap analysis e avviare la successiva fase di implementazione della soluzione individuata.

Nella seconda parte di questa serie di articoli, analizzeremo il secondo problema ricorrente nelle implementazioni LIMS: la gestione delle risorse da allocare al progetto.

Share This

X