Caso di studio: Il CIO solitarioAndrea Colleoni | Colleoni.INFO

Il CIO solitarioQuando il CIO si trova a dover prendere una decisione e

ha bisogno di un supporto indipendente.

Sintomi Il business richiede un nuovo servizio ed espone i suoi requisiti al CIO.

Il nuovo servizio ha tutte le caratteristiche per diventare un nuovo progetto informatico, dato che il servizio non è erogabile dal sistema informativo attuale.

Il CIO ha bisogno di fare uno scouting delle soluzioni disponibili e di realizzare il progetto.

Che fare? Personalizzare il proprio sostema informativo. Introdurre un nuovo prodotto che eroghi il servizio out-of-the-box e sviluppare un’integrazione. Realizzazare un nuovo software integrato.

Chi sono i cointeressati? I fornitori, che proporranno le loro soluzioni; nessun fornitore dirà che la propria soluzione non

va bene, ma che è la più adatta in quel contesto. Il business o la proprietà, proporranno i loro partner. Il CIO su cui ricadranno tutte le responsabilità se il progetto fallisce.

Problema n° 1: l’analisi Come è possibile ricavare da un insieme di requisiti del business i requisiti determinanti per

la comprensione della quota parte «informatica» del problema?

Soluzione tipica: Lasciare che sia il business a descrivere su un documento informale i propri bisogni e trasmettere o

condividere con i fornitori questi bisogni. I fornitori faranno poi la loro analisi dei requisiti.

La nostra soluzione : Esistono metodologie e strumenti affidabili e consolidati per produrre in tempi brevi un’analisi

completa dei requisiti in un contesto di sviluppo di software di qualità, comprendente: piano dei test, requisiti non funzionali, matrice delle competenze.

Benefici:

L’analisi da parte di un soggetto terzo, garantisce l’indipendenza della scelta. Il fornitore tenderà a porre in risalto la soluzione che produce il maggior margine.

Il CIO non ha bisogno di avere un ingegnere del software nel suo staff, ma ne richiede i servizi on-demand.

Con un insieme ordinato di requisiti è possibile produrre una stima più precisa.

Problema n° 2: la stima Come è possibile ricavare da un insieme di requisiti del business una stima affidabile del

costo dello sviluppo?

Soluzione tipica: Chiedere quotazioni a tutti i fornitori conosciuti.

La nostra soluzione : Esistono metodologie e strumenti per produrre in tempi brevi una stima del costo industriale di un

insieme di requisiti, a prescindere dalle tecnologie di implementazione.

Benefici:

La stima da parte di un soggetto terzo, garantisce l’indipendenza della scelta.

Il CIO non ha bisogno di avere un ingegnere del software nel suo staff, ma ne richiede i servizi al momento opportuno.

Con una stima, si può discutere del budget; con un insieme di requisiti no.

Con una stima si può scrivere un capitolato più preciso su cui chiedere una quotazione ai fornitori.

Problema n° 3: la direzione dei lavori A che punto siamo con lo sviluppo? Quando posso far vedere qualcosa al business?

Soluzione tipica: Tempestare di telefonate il PM del fornitore e chiedere incontri, SAL, verifiche e richiedere

tempi certi.

La nostra soluzione : Una direzione dei lavori terza, che coinvolge gli stakeholders con SAL periodici; un unico

interlocutore per progetti multi fornitore. Nessun rischio nascosto. Competenza tecnica nelle fasi dello sviluppo.

Benefici:

La direzione dei lavori da parte di un soggetto terzo, garantisce un’informazione indipendente.

Il CIO non ha bisogno di avere un PM nel suo staff, ma lo richiede in modalità on demand.

Il CIO non ha bisogno di riporre illimitata fiducia nel PM del fornitore.

Problema n° 4: la verifica Avevamo chiesto che fosse implementata questa funzionalità, ma nel software

consegnato non è implementata come la volevamo noi.

Soluzione tipica: Il forinitore chiede un addendum al contratto e sviluppa la funzionalità richiesta; nella migliore

delle ipotesi si può ottenere uno sconto commerciale dovuto all’incomprensione.

La nostra soluzione : Una verifica costante e in itinere rispetto al piano dei test. Mockups, deliverable frequenti e

processi AGILE per anticipare i problemi di interpretazione tra fornitore e business.

Benefici:

Si affronta il cambiamento, prima di aver affrontato il costo dello sviluppo di feature non richieste o non più utili.

Il fornitore è più motivato, e il business più coinvolto.

Oggettività dei test rispetto al ciclo di vita del progetto; minor probabilità di contenzioso con il fornitore.

Risultati finali Proprio come per la consulenza fiscale, anche il CIO non è solo e può

farsi consigliare da un consulente esterno on-demand. Non ci sono costi fissi, ma variabili e funzione della dimensione dei progetti. Non ci sono oneri di formazione, dato che i nostri professionisti sono esperti

aggiornati.

Maggiore proabilità di successo dei progetti software.

Minor costo relativo dei progetti falliti.

Oggettività nella comunicazione con business, fornitori, proprietà, management.

Colleoni.INFOIngegneria del software

http://www.colleoni.info/wp/slideshare