Ottimizzare la Gestione dei Progetti IT: Business Case e Attuazione

Introduzione

In questa prima parte si intende revisionare e analizzare le aree e le attività che la direzione deve coprire e che devono essere coinvolte affinché lo sviluppo dei progetti IT sia un meccanismo che agisca nella società o ente come un'attività globale di gestione informatica e, allo stesso tempo, una funzione (lo sviluppo) con un proprio costo.

Prima di procedere dobbiamo chiarire che la "direzione" a cui ci riferiamo è particolarmente quella di alto livello (amministratore delegato, presidente, manager funzionali) senza escludere alcun livello. In particolare, il grado di coinvolgimento del management dovrebbe essere direttamente proporzionale al loro livello di responsabilità, corrispondendo al più alto livello di leadership il ruolo di sponsor.

Attraverso i criteri di leadership si stabiliscono le strategie e le tattiche in grado di gestire e controllare concetti quali:

• Lo sviluppo organizzativo dei progetti, assegnando le necessarie risorse umane ed economiche o ricorrendo all'outsourcing. Queste risorse, a seconda della strategia da seguire, possono essere centralizzate nel ruolo dei Sistemi Informativi, o distribuite tra questo ruolo e le funzioni utente.
• I criteri e le commissioni che regolano e controllano le priorità e la redditività dei progetti da sviluppare, così come l'istituzione di un piano annuale, che deve includere i progetti in corso e in attesa.
• I piani d'azione che portano alla crescente "industrializzazione" a discapito dell'approccio "artigianale" nel processo di sviluppo dei progetti. Questi piani includono:
  • Quelli per la gestione e il controllo delle risorse utilizzate, che in ultima analisi portano alla conoscenza dei costi.
  • La previsione dei costi e dei benefici "a priori" e "a posteriori", sia a livello di progetto che dell'intero piano.
  • I passi che portano all'approccio "industriale" nello sviluppo dei progetti, come produttività, qualità, rispetto delle scadenze, ecc.

Tutte queste strategie e piani devono essere supportati da una ripartizione delle competenze per la gestione nelle varie aree aziendali o dell'ente che coinvolgono i livelli dirigenziali, sia lato utente che Sistemi Informativi.

Sono responsabilità della direzione utente, a tutti i livelli:

• Stabilire una strategia globale per informatizzare la propria funzione. Tale strategia deve essere in linea con i Sistemi Informativi e deve soddisfare le esigenze operative o i processi di business coinvolti nella funzione.
• Determinare i benefici che l'informatizzazione porterà a livello di progetto e di piano di informatizzazione. Questi vantaggi derivano principalmente da due parametri: il risparmio di budget e l'aumento della produttività delle proprie risorse umane.
• Impegnarsi sulla redditività del proprio piano di informatizzazione e dei singoli progetti, una volta noti i costi, sui quali, logicamente, a livello di progetto, i Sistemi Informativi devono intervenire. Questo ritorno dovrebbe basarsi su criteri di opportunità di investimento, valutazione dei costi e fattibilità tecnica.

Le responsabilità della direzione Sistemi Informativi:

• Stabilire una strategia globale di tecnologia informatica approvata dal top management, che affronti questioni come la centralizzazione vs decentralizzazione dell'hardware; il livello dei personal computer, le reti di gestione remota, i sistemi per ufficio, l'e-mail, la continuità operativa, e così via.
• All'interno dell'area Sviluppo dovrebbero essere responsabili di:
  • Definire un ambiente tecnico per la sperimentazione e lo sviluppo dei progetti e per la manutenzione delle applicazioni in produzione.
  • Attuare un piano di sviluppo e miglioramento delle attività di sviluppo in aree quali costi e procedure. Misure che aumentino la maturità dell'organizzazione.
  • Proporre, implementare e monitorare il piano di organizzazione delle risorse umane, sia per le organizzazioni centralizzate che decentrate o per gli analisti funzionali.
  • Assicurare la raccolta e l'allocazione delle risorse umane e dei contratti per ogni progetto di sviluppo.
  • Avere un piano annuale, attuale e aggiornato, dei progetti di sviluppo.
  • Stabilire un piano di formazione tecnica e vigilare sullo sviluppo professionale.

Ma affinché tutte queste strategie e responsabilità siano soddisfatte, l'impulso deve venire direttamente dal più alto livello di gestione della società o ente. È inutile provarci se questa condizione non è soddisfatta.

Tagliando e analizzando i diversi aspetti da considerare, vedremo nel corso delle sei sub-aree in cui è suddivisa la prima parte di questo libro:

• Come un sistema di gestione dello sviluppo del business
• Il "Business case"
• Generazione del Piano IT
• Piano di attuazione e controllo
• Coinvolgimento del management
• Norme e strumenti tecnici

Come un sistema di gestione dello sviluppo del business

Supponendo che le applicazioni siano la puleggia di calcolo nell'azienda o ente, e che siano la cinghia che muove le altre pulegge informatiche funzionali e dipartimentali, consideriamo come questa puleggia dovrebbe essere gestita secondo i principi di qualsiasi attività commerciale.

Questa attività, intesa come l'insieme delle attività di sviluppo, è contenuta nell'ambiente della società o dell'ente. Non è un business che, se non nelle aziende che lo svolgono come attività principale, produce fatture a clienti esterni, ma lo è dal punto di vista dei costi interni che genera, e che devono essere compensati e superati dai benefici interni prodotti. Questa è la base, e questo richiede la gestione diretta, da parte di tutte le direzioni e, in particolare, dalla direzione informatica e sviluppo della società o ente.

Come per qualsiasi attività, i parametri da considerare in questo caso sono: le risorse e i costi, sia umane che finanziarie, i benefici e i risparmi, e quindi, il saldo costi/benefici, le scadenze, le priorità e la soddisfazione dei clienti o utenti.

Questa attività dovrebbe essere, come le altre, governata da un piano annuale che definisca gli obiettivi da raggiungere in questo periodo di tempo e che possa essere rivisto, per mantenerne la validità, una o due volte all'anno (trimestralmente).

Per soddisfare questo principio di considerare lo sviluppo come un business redditizio o un'attività all'interno della società o ente, è inoltre necessario osservare alcune premesse nelle diverse organizzazioni:

Definizione

Il massimo livello di gestione deve definire il quadro d'azione, che si riassume in due parametri chiave: il primo si riferisce alla strategia e tattica informatica dell'azienda o ente (organizzazione centralizzata o decentralizzata, per affrontare aree e priorità, tipo di personal computer, email, ecc.), la seconda è relativa alle tattiche a breve termine in termini di investimenti annuali in risorse tecniche e umane (personale e contratti).

Decisione

Nell'ambito delle attività definite dal management di alto livello, i dipartimenti funzionali sono quelli che propongono i piani informatici, salvo, naturalmente, la possibilità di valutare i costi totali e la redditività dei singoli progetti.

Attuazione

È compito della funzione informatica (e sviluppo) stabilire il consolidamento e controllare l'avanzamento del piano di sviluppo dei progetti. Inoltre, questa funzione dovrebbe proporre strutture organizzative, che coinvolgano anche le funzioni utente, e rispondere agli approcci strategici. Questi approcci (accettati da tutte o alcune funzioni) si traducono in organizzazioni tattiche (annuali), le cui dimensioni devono essere stabilite e controllate dalla funzione informatica.

Controllo generale

Questo controllo deve essere esercitato dalle varie commissioni, definite dal management di altissimo livello, per garantire la conformità con i limiti stabiliti nel quadro. Tra questi, i più importanti sono: la redditività dei progetti e gli investimenti in impianti e risorse.

A queste premesse dovrebbero essere aggiunti chiari criteri, che tutte le funzioni devono soddisfare, concernenti la realizzazione dei benefici attesi.

Questa realizzazione dei benefici si basa sul controllo e sulla comunicazione. Ebbene, entrambi vengono eseguiti in parallelo quando si tratta di progetti individuali o gruppi di piccoli progetti dedicati normalmente a miglioramenti nelle applicazioni esistenti.

Per i progetti individuali, si procede alla revisione, una volta che l'applicazione è in produzione, verificando innanzitutto che soddisfi i requisiti utente stabiliti per affrontare le necessità della meccanizzazione proposta. Tale conformità è ovviamente essenziale.

I risparmi impegnati in base ai requisiti o alle specifiche della richiesta, in termini di risorse umane e finanziarie, devono essere applicati dalle funzioni o dagli organismi responsabili lato utente, contestualmente alla qualificazione dell'applicazione (che, ovviamente, è stata richiesta dal progetto).

Nella revisione di cui parliamo, si dovrebbero anche confrontare i costi effettivi sostenuti con quelli previsti nel "business case". La responsabilità delle deviazioni è condivisa tra la funzione utente, per l'analisi (se gli analisti funzionali sono funzionalizzati o decentrati), e la funzione informatica per lo sviluppo e l'implementazione.

Le informazioni della revisione vengono trasmesse dalla funzione informatica sia alla funzione utente (per conoscenza), sia al presidente del comitato o organo di redditività (per controllo), sia alle funzioni o organizzazioni responsabili della loro allocazione centrale di risorse umane e finanziarie (per la realizzazione dei risparmi da parte della funzione utente).

Nel caso di insiemi di piccoli progetti (si stima che ciascuno non superi i 3 mesi x uomo di sforzo in fase di sviluppo), dedicati a miglioramenti di un'applicazione, si effettuano revisioni mensili (o bimestrali) che riportino i costi totali e i risparmi realizzati per quelli che sono stati implementati nel periodo, alle stesse organizzazioni e persone (e per lo stesso scopo) descritte nel paragrafo precedente.

Infine, e un po' come sintesi del capitolo, è sufficiente dire che lo sviluppo è un'attività essenziale per ogni azienda o organizzazione. È fondamentale che soddisfi le premesse e le modifiche descritte e che tutti i progetti di sviluppo siano redditizi, cioè che funzionino per la funzione che li ha richiesti e, quindi, per l'azienda.

Il "Business Case"

Questo capitolo illustra la procedura da seguire per lo sviluppo di un progetto software, al fine di pianificare "a priori" il ritorno che si otterrà una volta che l'applicazione sarà installata e in uso.

Nel "business case" gioca un ruolo fondamentale la funzione proprietaria, nella persona del "proprietario".

Il "proprietario" è un dirigente che fa parte della funzione che ha richiesto il progetto informatico. Come tale, il 'proprietario' è lo sponsor del progetto, e sarà l'interlocutore per conto della funzione utente e degli utenti finali con l'organizzazione di sviluppo e manutenzione delle applicazioni.

Le sue responsabilità principali dalla proposta di progetto informatico fino a quando non diventerà un'applicazione in produzione, sono le seguenti:

• Quantificare i risparmi e i benefici che otterranno gli utenti finali (miglioramento della produttività, capacità di fare di più, migliore qualità, ecc.) quando l'applicazione sarà in produzione.
• Deve esprimere e documentare i requisiti e le caratteristiche che l'applicazione deve soddisfare e possedere.
• Deve fornire i dati di test necessari per verificare che l'applicazione soddisfi i requisiti.
• Deve definire il livello di riservatezza dei singoli componenti della futura applicazione (moduli, schermate, file, ecc.).
• Deve fornire agli utenti finali potenziali una formazione adeguata per utilizzare la futura applicazione.
• Dovrebbe infine autorizzare la fase di produzione (supervisionando la conversione dei file, se del caso), con cui il progetto diventa operativo.

In tutte queste responsabilità, il "proprietario" deve essere aiutato e supportato dagli analisti funzionali.

Inoltre, gli analisti funzionali devono supportare il proprietario nelle sue responsabilità dopo la "nascita" dell'applicazione.

Queste responsabilità del proprietario durante il ciclo di vita dell'applicazione sono:

• Convalidare che il funzionamento dell'applicazione sia coerente con i requisiti e le caratteristiche stabiliti nella proposta di progetto. La convalida permetterà di realizzare i risparmi e i vantaggi previsti dalla proposta.
• Essere il canale tra gli utenti finali e la funzione Sistemi Informativi per mantenere aggiornate le liste degli utenti e le distinzioni relative all'accesso riservato.
• Controllare che le esecuzioni, le performance, le proiezioni, ecc. effettuate in produzione siano corrette (i file siano conformi per contenuto e tempi, e gli output si verifichino come previsto) e complete.
• Essere il punto focale per i suoi utenti finali in termini di nuove esigenze, miglioramenti, modifiche, ecc. relative alle applicazioni e avviare la richiesta appropriata all'organizzazione di sviluppo e manutenzione delle applicazioni.

È, in definitiva, il coordinamento e la rappresentanza degli utenti finali per la "loro" applicazione, in relazione con la funzione Sistemi Informativi, sia per la produzione che per lo sviluppo.

Ciò significa che qualsiasi progetto di sviluppo, fin dalla sua proposta, da parte del proprietario attuale o futuro - sia che si tratti di un nuovo progetto di sviluppo, sia di una modifica o miglioramento di un'applicazione esistente - deve basarsi sulla redditività o sull'esplicita approvazione del senior management (o di un suo delegato).

I componenti di base per la valutazione della redditività sono il confronto tra costi e risparmi o benefici. Questi componenti devono essere pianificati in fase di requisiti e devono essere impegnativi, sia per il proprietario che per lo sviluppatore, fino alla fase finale di analisi e progettazione esterna.

Eventuali variazioni che si verificano durante lo sviluppo, il testing, l'integrazione e l'installazione dovrebbero innescare un riesame della redditività da parte del proprietario. Se questa modifica ha prodotto un rendimento negativo del progetto (cioè, se i costi superano i risparmi), è necessario ottenere l'autorizzazione appropriata dalla persona delegata dal senior management (di solito il controller o il revisore generale) per continuare lo sviluppo del progetto.

Durante tutto lo sviluppo, dobbiamo confrontare l'evoluzione dei costi effettivamente sostenuti rispetto al totale preventivato e confrontare ciò con la parte corrispondente del lavoro complessivo svolto. Questo confronto, che effettua il project manager e viene rivisto nelle riunioni di follow-up del progetto, è fondamentale, dato che, dati i benefici, è necessario monitorare che i costi non si discostino da quelli previsti. In caso di deviazione, e quando questa rende o rischia di rendere il progetto non redditizio, gli sviluppatori devono interrompere e chiedere l'autorizzazione ai massimi dirigenti per continuare. Chiaramente, questi casi sono spesso accompagnati dalla necessità di diversi tipi di prove e informazioni che non sono molto gradite agli sviluppatori.

In ogni caso, dato che il mantenimento della redditività impegnata per intraprendere lo sviluppo di un progetto è essenziale, qualsiasi circostanza che la diminuisca, la danneggi o la renda o sia idonea a renderla negativa, deve essere conosciuta e/o autorizzata dalla direzione e deve essere comunicata alla direzione utente e al proprietario.

Il modo per realizzare la gestione e il controllo di un "Business Case" per ogni progetto del piano annuale deve coinvolgere:

• Un piano di lavoro per controllare i progetti. Questo è il capitolo 7.
• Il coinvolgimento del senior management, della direzione utente e del proprietario, e della leadership dello sviluppo.

L'articolazione di un organismo per garantire e coordinare questo secondo punto dipende dalla dimensione aziendale, dalla sua dispersione geografica o concentrazione, dal grado di autonomia o delega informatica nelle diverse organizzazioni, dalla centralizzazione o decentramento informatico nel loro concetto operativo o di budget, ecc.

In ogni caso, l'istituzione di questo organismo è essenziale, in quanto è il garante, a livello di principio, per la società o ente, della redditività dello sviluppo delle applicazioni. In parallelo, è come il comitato che autorizza la produzione e la commercializzazione di un nuovo prodotto in un'azienda manifatturiera.

Questo organismo può assumere nomi diversi, come ad esempio Comitato di Gestione Informatica, Comitato di Information Technology, Comitato Informatico o di Performance delle Applicazioni, Comitato Utenti Informatici, e così via. Ma il suo obiettivo di fondo è che l'azienda abbia un piano di sviluppo progetti IT in corso che siano convenienti e individualmente redditizi.

Questo organismo dovrebbe riunirsi con una frequenza predefinita dal suo presidente (ad esempio, tre volte l'anno). Il suo presidente dovrebbe essere, come già notato, un senior manager o un amministratore della più alta dirigenza della società o ente.

Parte della sua performance complessiva, e il suo massimo a livello di costi, deve essere definito dal top management per quanto concerne lo sviluppo delle applicazioni, cioè le risorse umane e tecniche (hardware e comunicazione) per i sistemi e il piano, il budget previsto per l'outsourcing, i progetti vitali, importanti e notevoli per la dirigenza (di solito coinvolgono più unità o funzioni dell'organizzazione) e così via.

Il segretario di questo organismo deve anche assicurare la logistica e l'agenda delle riunioni, l'esistenza di dati che diano continuità alle questioni in sospeso e la gestione e il controllo del supporto contenente i dati richiesti dai progetti. Quest'ultima richiesta rende opportuno che il segretario o il suo dipartimento sappiano utilizzare le applicazioni informatiche e i linguaggi utente finale.

I partecipanti alle riunioni convocate dal presidente sono i direttori delle funzioni utente (che richiedono progetti), il CIO, il direttore dello sviluppo e il responsabile dei "Sistemi di Assicurazione" o garante della qualità del piano di attuazione (questa responsabilità è discussa nel capitolo 5).

I relatori sono i direttori degli analisti funzionali (che, quando le organizzazioni sono funzionali all'utente, dipendono gerarchicamente da queste funzioni, ma funzionalmente dalla direzione dello sviluppo di base) per conto dei proprietari e degli utenti, per il loro funzionamento e supporto nelle presentazioni dei progetti richiesti dai direttori dello sviluppo per tali rapporti o relazioni su questi progetti.

Al fine di calcolare la redditività, o il tempo necessario a recuperare l'investimento, di un progetto di sviluppo, è necessario conoscere i costi e i risparmi o vantaggi.

I costi si verificano prima che il progetto diventi operativo, cioè prima che l'applicazione sia operativa o utilizzabile dagli utenti.

I risparmi o i benefici si verificano da quando gli utenti iniziano a utilizzare l'applicazione in produzione.

I componenti che fanno parte dei costi di un progetto di sviluppo, sia nuovo che di modifica di un'applicazione esistente, sono: le persone, l'outsourcing e le attrezzature.

Le persone coinvolte in tutto lo sviluppo hanno competenze ed esperienze diverse, ma si trovano sia nell'organizzazione utente - i proprietari richiedenti e futuri dell'applicazione - sia nell'organizzazione informatica.

Così, per la funzione o organizzazione utente, sono coinvolti gli utenti finali futuri, rappresentati dal proprietario e dagli analisti funzionali che lo supportano. Per l'organizzazione informatica sono coinvolti gli sviluppatori (analisti e programmatori interni) e i professionisti che operano nel centro di elaborazione.

L'unità di base di misura è il mese x uomo o persona, anche se in alcuni casi - più comune negli ambienti di produzione - si usa la settimana al posto dei mesi.

Questa unità è essenziale per pianificare le varie attività distribuite sul progetto e realizzate dai diversi gruppi di persone descritti, ma poiché il costo mensile di ogni tipo di persona non è lo stesso, è necessario monetizzare il costo totale delle persone (il costo mensile di ogni persona deve essere calcolato e aggiornato dal dipartimento o organizzazione che ne ha la responsabilità - Pianificazione, costi del personale, ecc. - o, in ultima analisi, dall'organizzazione informatica).

L'outsourcing, quando si verifica, riguarda il costo del lavoro per diverse persone o gruppi di cui sopra. La facilità di esternalizzazione diminuisce, o può diminuire, in termini generali: (1) a seconda del tipo di attività, (2) delle caratteristiche del subappaltatore e (3) delle circostanze dell'azienda che affida. Di solito questa facilità diminuisce quando i processi passano dallo sviluppo all'analisi organica, funzionale e utente/proprietario, così come all'esercizio.

In ogni caso, quando l'outsourcing riguarda un'area, è necessario conoscere il costo applicato alle aree corrispondenti. Tale costo, così come quello non previsto dal contratto, devono essere noti prima di iniziare il progetto.

All'interno del concetto di outsourcing può rientrare l'acquisto di un'applicazione o di un set o "pacchetto" di applicazioni che risolvano, anche se non al cento per cento, il problema per cui è stato avviato il progetto di sviluppo.

Il terzo componente, le attrezzature, si riferisce, se del caso, al costo totale che deve essere sostenuto per l'acquisizione di hardware, software applicativo o altri dispositivi necessari per lo sviluppo, il collaudo o l'esercizio.

Supponiamo, per esempio, che ci sia un progetto per meccanizzare la movimentazione delle merci in un magazzino, e che sia necessario utilizzare pistole lettori di codici a barre che, via radio o via cavo, trasmettano informazioni a una centralina di controllo della comunicazione. In questo caso, tutti i costi relativi alla lettura e alla trasmissione dovrebbero essere inclusi nei costi del progetto.

Questo stesso principio si applica quando il progetto, per sua natura, richiede una considerevole estensione dell'hardware e/o del software del centro di elaborazione, sia per i test che per l'esercizio.

Infine, una volta conosciuti gli elementi e la loro somma, e prima di analizzare i risparmi, è necessario sapere se questo costo è conveniente per l'azienda. È inoltre auspicabile, anche se il costo non è eccessivo per il budget della società o organizzazione, esaminare la possibilità di realizzare il progetto - in tutto o in parte - con strumenti informatici e linguaggi utente finale richiesti dalla funzione stessa.

Il calcolo dei risparmi o benefici che il progetto produrrà quando, già in funzione, sarà disponibile per gli utenti, passa dall'essere una stima (in fase di requisiti) all'essere un impegno (una volta completata l'analisi funzionale).

Proprio come nel mondo degli affari i costi di sviluppo in generale - e non con eccessivo formalismo e rigore - vengono spesso stimati nella proposta di progetto, i risparmi o i vantaggi del progetto/applicazione vengono spesso considerati con molta meno modalità e rigore. Proprio questa è una causa importante che innesca una spirale di mancanza di impegno da entrambe le parti:

• Per gli sviluppatori, nella stima e nel controllo dei costi.
• Per gli utenti, nella stima e nella revisione dei benefici.

Ebbene, l'unico modo per spezzare questa spirale è agire su entrambi i punti.

Poiché stiamo parlando di risparmi o benefici, dobbiamo mettere in chiaro che per gli sviluppatori - e naturalmente per l'azienda o l'organizzazione - garantiscono che il loro lavoro sia utile, il che a sua volta produce un effetto motivante affinché il "circolo vizioso" descritto diventi un "circolo virtuoso".

Lo sviluppatore, non conoscendo il problema dell'utente, non conosce il valore del proprio lavoro, e se non vede il coinvolgimento e l'impegno dell'utente, perde l'incentivo a fare bene e in tempo.

I risparmi o i vantaggi, naturalmente, li deve fornire, in modo esplicito, la funzione utente che richiede lo sviluppo, in quanto saranno loro ad applicare le proprie risorse, sia umane che monetarie.

Ci possono essere diversi modi per quantificare i risparmi, ma ci sono due parametri fondamentali da stabilire:

• Per quanto tempo si accumulano questi risparmi.
• Con quale "mix" di persone e/o denaro e, all'interno di ciascuna di queste variabili, distinguendo tra "Riduzione" e "Evitamento".

Poiché i risparmi sono previsti per anni, la prima domanda è il tempo o gli anni da considerare, al fine di accumularli in modo semplice o ponderato.

Questo dovrebbe tener conto del tempo previsto in cui l'applicazione non verrà modificata in modo sostanziale. Ci possono essere diversi criteri al riguardo, basati su informazioni o stime "più o meno" statistiche sull'installazione nella società o ente.

La nostra migliore stima è di considerare che per due anni dopo il suo inizio in produzione, l'applicazione non venga alterata in modo tale da variare i benefici annuali attesi e impegnati. Questo criterio dovrebbe essere stabilito dall'organismo di cui al punto 3.1.

Per intraprendere la quantificazione dei risparmi deve essere determinato il "mix" o la somma, che provengono da risorse umane e da risorse monetarie.

Per ciascuna di queste risorse si deve decidere quante sono le "Riduzioni" e quanti gli "Evitamenti".

Per "Riduzioni" si intendono le persone - in mesi x uomo - e/o il denaro - di solito migliaia di pesetas - il cui utilizzo e/o spesa cessa nella funzione o area utente quando l'applicazione è in produzione. Logicamente, queste risorse faranno parte di quelle impegnate per l'operazione o il processo proposto informatizzato.

Per "Evitamenti" si intendono le risorse umane e/o il denaro (nelle stesse unità di prima) che non sarà necessario aumentare nella funzione o area utente, ma per le quali è previsto un aumento dei volumi di informazioni commerciali o da trattare (nuovi prodotti, nuovi clienti, ecc.).

Un progetto di sviluppo, dopo essere stato in funzione, è conveniente se i risparmi o i vantaggi sono uguali o superiori al suo costo. Ma quando? Subito dopo l'implementazione o tra cinque anni?

Il punto o momento nel tempo in cui la somma dei benefici o risparmi annuali eguaglia il costo o l'investimento, è chiamato "Payback" (RI). Da questo punto l'investimento inizierà a essere redditizio, perché i benefici superano i costi sostenuti.

Prima di stabilire il valore del RI, separiamo i progetti di sviluppo inclusi nel piano annuale in due tipi:

• Progetti "identificati individualmente" il cui sforzo di sviluppo è superiore a tre mesi x uomo.
• I progetti non identificati individualmente, generalmente destinati a "migliorare" le applicazioni esistenti in produzione.

I primi sono quelli che corrispondono alla definizione e per i quali il RI è fissato a due anni (o meno), dal momento che in questo periodo si considera che i vantaggi di un'applicazione si mantengono e si accumulano.

I secondi sono quelli il cui sforzo di sviluppo individuale è stimato, in linea di principio, in meno di tre mesi x uomo. La maggior parte di essi si riferisce a piccoli miglioramenti nelle applicazioni esistenti, quindi sono generalmente indicati come progetti di "miglioramento".

Poiché sarebbe troppo lungo includerli individualmente nel piano annuale e sarebbe anche molto costoso controllarli con gli stessi criteri degli altri progetti, è più pratico e operativo raggruppare l'impegno stimato per insiemi di esecuzione o "pacchetti" (a cui si riferiscono).

Questo permetterà di semplificare il piano annuale senza perdere il controllo della redditività individuale, dal momento che questa responsabilità il presidente dell'organismo o del comitato di redditività può delegarla al direttore dello sviluppo che gestisce l'applicazione di riferimento nel piano. In ogni caso, il direttore dello sviluppo non può iniziare un progetto di "miglioramento" e assumersene la responsabilità senza accertarsi che sarà redditizio; se in un caso non lo è, deve chiedere l'autorizzazione al presidente per iniziare.

Questo tipo di progetti di "miglioramento", anche se richiedono poco sforzo, sono spesso molto importanti e urgenti perché sono solitamente causati da nuovi imperativi legali, commerciali, di controllo, e così via. Questi vincoli determinano una grande urgenza per l'installazione e grandi risparmi a breve termine.

Pertanto, per i progetti di "miglioramento", sia singoli che in pacchetti, si applica un RI di un anno (o meno). Ciò significa che il RI è di un anno o meno per ogni progetto di "miglioramento", poiché il denominatore (costi) è la metà o meno del numeratore (risparmi in due anni).

Infine, non possiamo dimenticare che nel piano annuale dei progetti ci sono anche progetti di manutenzione.

Nel piano annuale devono essere inclusi come progetti di manutenzione solo quelli relativi alla manutenzione CORRETTIVA, discussi in dettaglio, insieme ad altri tipi di manutenzione, nei capitoli 5 e 10.

Basti dire qui che questo tipo di progetto non è redditizio e, quindi, nel piano annuale deve essere specificato in modo chiaro, sia l'impegno previsto per ciascun progetto che l'applicazione a cui si riferisce. Dovrebbe ovviamente essere rigorosamente controllato nel tempo per garantire l'assenza di eccessive "spese", poiché gli sforzi consumati in tali progetti sono come la dissipazione di calore in una macchina che proviene da un'energia "inutile", cioè non hanno alcun beneficio o risparmio in cambio.

Sulla base di quanto esposto qui, calcoliamo il rapporto, che noi chiamiamo fattore, tra risparmi e costi:

Risparmi (due anni in produzione)

FATTORE =

Costi (sviluppo)

I risparmi si ottengono sommando quelli relativi alle risorse umane (persone) e quelli relativi alle risorse monetarie (migliaia di pesetas - KPTAS -).

In entrambi i casi si applica una ponderazione che riflette se il risparmio deriva da "Riduzioni" o "Evitamenti", come spiegato in 3.2.2.

Questi pesi sono:

Pertanto, il risparmio di risorse umane sarà, se del caso:

Costo annuale di tale persona (amministrazione, vendite, finanza, personale, ecc.) x numero X di persone all'anno x due anni x il coefficiente correttore applicabile.

Nel caso in cui una persona avesse costi differenti, perché svolge diversi tipi di lavoro e/o ha pesi diversi, si procede alla somma corrispondente. Questi dati sono forniti dalla funzione richiedente e incidono sulle proprie risorse umane.

Allo stesso modo, anche se più semplice, il risparmio da risorse di tesoreria sarà calcolato, se del caso, come segue:

X KPTAS all'anno x due anni x ponderazione.

Questi dati sono forniti dalla funzione richiedente e si riferiscono alle proprie risorse monetarie che saranno influenzate allo stesso modo quando il progetto verrà implementato.

I costi si ottengono sommando quelli previsti per il progetto, basati sui mesi netti dedicati al progetto:

Mesi x persona sviluppo + mesi x persona analisti + mesi x persona contratto + mesi x persona utenti + mesi x persona elaborazione centrale (soprattutto per il passaggio alla produzione).

A questi costi, in KPTAS, dovrebbero essere aggiunti, se del caso, le attrezzature aggiuntive speciali o i software di progetto.

Infine, si determinerà il valore del FATTORE.

Come detto sopra, il RI dovrebbe essere diverso, a seconda del tipo di progetto.

• Progetti "identificati individualmente" il cui sforzo di sviluppo individuale è superiore a tre mesi x uomo:

Il fattore deve essere uguale o maggiore di 1. Ciò significa che il RI è di due anni o meno, dal momento che nel calcolo, il denominatore (costi) è uguale o inferiore al numeratore (risparmi in due anni).

• Per i progetti di "miglioramento", o insiemi di essi, il cui sforzo di sviluppo individuale non supera i tre mesi x uomo netti:

Il fattore deve essere uguale o maggiore di 2. Ciò significa che il RI è di un anno o meno per ogni progetto di "miglioramento", poiché il denominatore (costi) è la metà o meno del numeratore (risparmi in due anni).

Infine, non possiamo dimenticare che nel piano annuale dei progetti ci sono anche progetti di manutenzione.

Nel piano annuale devono essere inclusi come progetti di manutenzione solo quelli relativi alla manutenzione CORRETTIVA, discussi in dettaglio, insieme ad altri tipi di manutenzione, nei capitoli 5 e 10.

Basti dire qui che questo tipo di progetto non è redditizio e, quindi, nel piano annuale deve essere specificato in modo chiaro, sia l'impegno previsto per ciascun progetto che l'applicazione a cui si riferisce. Dovrebbe ovviamente essere rigorosamente controllato nel tempo per garantire l'assenza di eccessive "spese", poiché gli sforzi consumati in tali progetti sono come la dissipazione di calore in una macchina che proviene da un'energia "inutile", cioè non hanno alcun beneficio o risparmio in cambio.

La questione della redditività che abbiamo visto e analizzato, come la maggior parte delle questioni di business, può essere affrontata anche in altri modi e con altre alternative, a discrezione della società o ente.

Uno dei modi più noti e utilizzati, in caso di sviluppo di sistemi operativi o applicazioni, è l'accumulo dei costi di sviluppo, previsti ed effettivi, anno per anno, e allo stesso modo l'accumulo dei benefici o risparmi, anch'essi anno per anno, a partire dalla data di disponibilità delle applicazioni. Logicamente, il recupero o il ritorno sull'investimento si verifica quando le due grandezze si eguagliano.

In questi casi di grandi sistemi o applicazioni (alcuni sono misurati in milioni di righe di codice) il recupero degli investimenti va oltre i due anni.

Quello che dovrebbe essere chiaro è che, per i progetti di sviluppo software, la decisione di una società o ente dovrebbe basarsi sulla redditività individuale e, eccezionalmente, sull'approvazione formale ed esplicita del top management, e mai sull'"ispirazione" intuitiva o sull'"abilità dialettica", che spesso si affidano al potere della gerarchia.

Generazione del Piano Informatico

Sembra ovvio affermare che qualsiasi azienda o ente debba avere un piano annuale IT - e ci riferiamo in particolare al piano dei progetti di sviluppo - che venga rivisto due o tre volte l'anno. Le revisioni mantengono aggiornato il piano, anche se dopo la revisione potrebbe rimanere lo stesso.

In generale, se si chiede a qualsiasi azienda se dispone di un piano di progetti di sviluppo, la risposta è sì. In effetti hanno un piano, ma è "il loro" piano, con "i loro" criteri, che generalmente non sono sufficientemente formali e coerenti, anche se sono il minimo necessario per "orientare".

Vediamo cosa dovrebbe contenere almeno un piano dei progetti di sviluppo e cosa dovrebbe includere:

• Un piano di sviluppo dovrebbe essere l'unico punto di riferimento per sapere cosa si sta facendo e cosa si farà.
• Questo piano dovrebbe servire a pianificare e allocare le risorse umane da dedicare alla sua realizzazione.
• Deve contenere i progetti che sono in fase di sviluppo, anche se iniziati anni fa, e le risorse che verranno consumate fino alla data effettiva del piano.
• Il piano di sviluppo deve contenere i progetti in attesa di iniziare, e le risorse umane che verranno consumate annualmente, per la durata necessaria.
• Il piano deve contenere i progetti che sono redditizi (o hanno un permesso esplicito) in linea di principio - in fase di requisiti - o confermati - dopo l'analisi funzionale -.
• Il piano deve contenere, a livello di progetto, la quantità di risorse umane da utilizzare ogni anno, distinguendo tra quelle della funzione utente - fondamentalmente analisti funzionali - e i subappalti prevedibili, e quelle relative agli sviluppatori - fondamentalmente analisti e programmatori interni - e all'outsourcing. Ovviamente questi concetti devono essere aggregati a livello di funzione utente e a livello di azienda o ente.
• L'attuale piano di sviluppo dovrebbe essere l'ultimo di una serie di piani e quindi dovrebbe essere una continuazione del precedente, e questo, a sua volta, del suo predecessore. Negli ultimi tre o quattro piani si deve essere certi che non siano "scomparsi" progetti avviati in precedenza - in modo illegittimo e senza l'approvazione dell'organismo che sanziona il piano - così come gli aumenti negli sforzi per i progetti di sviluppo.

Il piano dei progetti deve essere costruito "dal basso", cioè dalle necessità di elaborazione degli utenti finali. Si deve ammettere, come punto di partenza, che chi conosce i problemi delle operazioni di business sono gli utenti e, quindi, che sono loro a poter proporre le soluzioni.

Si deve capire che i problemi degli utenti finali non sono limitati a quelli che i professionisti possono rilevare, ma includono anche quelli rilevati dalla loro direzione, che ha il compito di gestire e ottimizzare i propri obiettivi di business come parte degli obiettivi della società o ente.

Ciò pone le basi per le esigenze informatiche, cioè, il "vivaio" del piano della funzione utente.

Queste esigenze di sviluppo di progetti IT vengono consegnate ai "Dipartimenti IT di Funzione", che sono composti da analisti funzionali e il cui primo obiettivo è la conoscenza e l'analisi del problema della funzione e una prima diagnosi di fattibilità per la soluzione informatizzata.

Questi dipartimenti, come abbiamo accennato in 3.1, devono essere integrati con l'organizzazione informatica dell'azienda o ente attraverso una subordinazione funzionale che determini e approvi, tra le altre cose, la dimensione di questi dipartimenti, le competenze richieste per accedervi, le categorie e la promozione al loro interno e i possibili spostamenti tra i dipartimenti funzionali delle diverse funzioni.

Ebbene, questi dipartimenti funzionali costituiscono il primo anello nel processo di generazione del piano delle applicazioni. Una volta conosciuti gli embrioni dei progetti IT - che risolveranno i problemi di gestione, "nel senso più ampio della parola", della loro funzione - devono consolidare le possibili aree in cui è suddivisa la funzione, suggerendo i proprietari delle future applicazioni e interagendo con gli attuali proprietari delle applicazioni esistenti.

Successivamente, i requisiti devono essere consolidati dalla funzione, ma prima di presentare il piano al direttore della propria funzione, si devono ottenere dai proprietari attuali o futuri i vantaggi che deriveranno alla funzione e quindi alla società o ente dalla realizzazione dei progetti.

È necessario valutare anche gli sforzi da effettuare da parte della funzione - sia gli analisti funzionali che gli utenti - per lo sviluppo prevedibile di questi progetti.

Prima di presentare questo piano alla direzione della propria funzione, è necessario confrontarsi con il dipartimento di sviluppo e scambiare informazioni sui progetti contenuti in questo piano per concordare le stime dello sforzo di sviluppo individuale.

Prima della quantificazione di questo piano "grezzo", è necessario che il dipartimento si incontri con la dirigenza della sua funzione per analizzare aspetti quali:

• Quali progetti sono in linea di principio più redditizi.
• Quali sono i progetti più importanti, strategici o vitali.
• Quale sforzo e costo la funzione può affrontare con le risorse disponibili.

Parallelamente a queste attività funzionali, l'organizzazione di sviluppo studia le attività e le stime dei tempi per ogni progetto.

Durante questa fase di gestazione sono necessari diversi incontri preliminari e scambi di informazioni tra analisti funzionali e sviluppatori per costruire il piano, che ovviamente sarà costituito da: nuovi progetti, prosecuzione di progetti di sviluppo, modifiche significative alle applicazioni esistenti, miglioramenti alle applicazioni o a catene di applicazioni, e manutenzione correttiva.

Di questi, solo gli ultimi componenti sono solitamente stimati dagli sviluppatori stessi; il resto deve essere stimato da analisti e sviluppatori, ciascuno nel proprio ambito di competenza.

Una volta che il piano operativo con i costi e i risparmi previsti è pronto e accessibile, il dipartimento funzionale verifica la redditività individuale e convalida il piano, classificando i progetti secondo alcuni criteri di priorità - di solito la redditività - distribuiti tra le diverse aree che compongono la sua funzione.

Ora è quando, con l'approvazione preliminare della funzione, il dipartimento IT per ogni funzione invia una copia del suo piano proposto al segretario del comitato di redditività. Il dipartimento di quest'ultimo:

• Verifica la presenza di tutti i dati necessari.
• Somma i valori e verifica la realizzabilità del piano.
• Include i progetti di manutenzione, che sono stimati dagli sviluppatori.
• Consolida i vari piani funzionali e ottiene un totale prima della riunione del comitato o organismo.

Se i totali rientrano nei limiti stabiliti dai vertici aziendali, soprattutto in termini di:

• Risorse umane, funzionali e di sviluppo.
• Costi di subappalto e costi specifici per la realizzazione del piano, allora si procede allo svolgimento delle riunioni del comitato, organismo, e così via. Abbiamo già discusso nel capitolo precedente. In caso contrario, cioè se le risorse o i costi non rientrano nei limiti previsti, il segretario informa le funzioni corrispondenti affinché regolino il piano. Una volta regolato e presentato, si procede alla riunione di revisione della redditività.

In questa riunione, ogni funzione dovrebbe discutere ciascuno dei propri progetti, che, come abbiamo detto, devono soddisfare i requisiti di redditività richiesti. Inoltre, l'organizzazione di sviluppo deve anche commentare i progetti di manutenzione.

Il presidente della riunione del comitato o organismo deve disporre di criteri di redditività e di autorità per ascoltare le ragioni e la casistica dei progetti funzionali, sanzionare o alterare i piani funzionali - cambiamento delle priorità, delle risorse, messa in discussione dei costi, o per altri motivi di alto livello (che rappresenta o a cui appartiene) -. Nel caso di cambiamento di piano, le funzioni interessate dovrebbero essere riconvocate per l'esame e l'approvazione dei nuovi piani.

Queste possibili iterazioni dovrebbero essere brevi e, in casi eccezionali, se persistono le discrepanze, devono essere portate a un comitato o riunione della dirigenza, in cui la funzione interessata dovrebbe esporre la discrepanza e proporre possibili soluzioni.

Il segretario redige un verbale che viene inviato alle funzioni, con gli eventi importanti emersi durante la riunione, e presenta il verbale sottoscritto dal presidente.

Una volta approvati i piani funzionali e, quindi, quello della società o ente, ogni funzione può stabilire le priorità tra i propri progetti - basandosi sugli sviluppatori per quando devono intervenire -.

Questo piano consolida le priorità funzionali e viene distribuito a tutte le funzioni. Questa distribuzione è effettuata dal segretario del comitato di redditività:

• Affinché il piano dei progetti di sviluppo sia conosciuto da tutti i ruoli (dirigenti e "dipartimenti funzionali").
• L'attuale piano è l'unico punto di riferimento per tutta l'azienda per sapere cosa si sta sviluppando e cosa si svilupperà in termini di applicazioni informatiche.

Senza dubbio l'esperienza - soprattutto quando è positiva - cede alla tentazione di pontificare su questo argomento. Nulla è più lontano dalla nostra intenzione.

In realtà, studi come quello di D.J. Martin Buss analizzano alternative per stabilire le priorità dei progetti che, a nostro avviso, non sono molto diverse da quella descritta, ma il processo è più elaborato.

Oltre a quelli citati, molte aziende, come abbiamo detto, hanno "il loro" processo per generare il piano dei progetti e assegnare le priorità; alcuni saranno migliori e altri peggiori, ma tutti si stanno evolvendo, migliorando e includendo aspetti parziali o nuovi.

Ciò che è chiaro è che il processo utilizzato deve soddisfare determinati requisiti per garantire alla società o ente, e a qualsiasi eventuale revisione o audit, aspetti quali:

• Che il processo in atto sia concordato con coloro che vi sono coinvolti e che sia approvato dal senior management o da qualcuno con potere esecutivo a cui sia stato delegato.
• Che ci sia (si dovrebbe dire nel processo, se esiste) un elenco dei progetti in fase di sviluppo e un altro dei progetti in sospeso per qualsiasi motivo (mancanza di risorse, bassa priorità, ecc.).
• Che ogni progetto - sia in sviluppo che in sospeso - abbia stime di sforzo, costo e risparmio.
• Che si possa dimostrare che la direzione (sia quella esecutiva che quella utente) è coinvolta, interessata e impegnata nei progetti di sviluppo.
• Che i progetti siano redditizi e prioritari per le funzioni utente e per l'azienda o ente.
• Che il piano attuale, se del caso, abbia continuità con il precedente, e il secondo con il primo.
• Che siano noti i progetti annullati nel corso dell'ultimo anno, dopo l'inizio dell'analisi e/o dello sviluppo, così come i costi sostenuti, le motivazioni e le approvazioni esistenti.

Piano di Attuazione e Controllo

Lo scopo del piano di sviluppo delle applicazioni software, come di qualsiasi altro piano, è la sua realizzazione, secondo quanto stabilito e nel modo più rigoroso e preciso possibile, pur mantenendo una certa flessibilità - controllata al massimo - se le circostanze lo richiedono.

Come la generazione del piano delle applicazioni, discussa nel capitolo precedente, che richiede una certa sincronizzazione tra le funzioni utente e l'organizzazione di sviluppo, l'attuazione del piano richiede, durante lo sviluppo di ogni progetto, oltre alla sincronizzazione - nei test di catena, nel sistema, con la produzione, nell'istruzione e formazione degli utenti, e così via - anche tra le organizzazioni sopra menzionate e i processi del centro di elaborazione o sede operativa.

Tutte queste sincronizzazioni, unite alla verifica della maturità organizzativa e al controllo, si trovano nel piano di attuazione e monitoraggio dell'organizzazione di sviluppo.

Questa organizzazione di sviluppo, così come la linea di produzione in una fabbrica, deve dimostrare, oltre all'attuazione del piano, l'eccellenza nelle procedure di lavoro, la crescente qualità dei prodotti e il raggiungimento degli obiettivi numerici del piano di controllo. Questo significa una maggiore trasparenza delle informazioni verso gli utenti e le altre funzioni, con l'obiettivo principale della massima efficienza nella realizzazione del piano.

Gli ingredienti o componenti coinvolti nella realizzazione del piano vengono discussi in risposta alle domande classiche: chi, cosa, come e quando.

Cosa fare

Il piano di sviluppo, o delle applicazioni, o dei progetti di sviluppo - come lo si voglia chiamare - è il compito, e si compone di:

• Nuovi progetti di sviluppo (non avviati).
• Continuazione dei progetti di sviluppo (già iniziati).
• Modifiche e/o miglioramenti alle applicazioni esistenti.
• Manutenzione delle applicazioni esistenti.
• Implementazioni in produzione di qualsiasi modifica in questo ambiente derivante da uno dei quattro punti precedenti.

Chi dirige, coordina e controlla

Questo aspetto è importante e la risposta dipende dal tipo di organizzazione IT dell'azienda o ente - centralizzata, semi-decentrata, e così via - e dal tipo di progetto - funzionale, multifunzionale, grande, piccolo, e così via -.

Per analizzare queste possibilità è necessario chiarire le varie posizioni e responsabilità, manageriali e professionali, che possono essere coinvolte durante lo sviluppo di un progetto.

Project Leader o Coordinatore del Progetto, è la persona che guida la realizzazione di un progetto, che stabilisce il piano, lo concorda con gli individui o i dipartimenti coinvolti, coordina le interazioni tra di loro e informa la direzione informatica e/o funzionale. Questa persona non ha alcun controllo gerarchico sugli individui o dipartimenti coinvolti nello sviluppo. Il profilo di competenze si basa più sulla sua capacità di organizzare, pianificare e coordinare, che sulla sua formazione tecnica (anche se dovrebbe averne conoscenza).

Il ruolo di "Project Leader" è difficile da svolgere a causa della difficoltà di coordinare (che a volte è una direzione fittizia) persone o dipartimenti che non dipendono gerarchicamente da esso. Se la scelta non è buona, può diventare un "persecutore" o "accusatore", il che può influenzare negativamente il progetto.

Questa figura può essere appropriata quando l'organizzazione IT è consolidata e il progetto appartiene e interessa una singola funzione utente. In questo caso, tale responsabilità può essere assunta in linea di principio da un analista funzionale che soddisfi i requisiti.

Questo tipo di organizzazione (con un "Project Leader") ha il vantaggio che, se durante lo sviluppo, per vari motivi, ci sono "picchi" o "cali" del carico di lavoro, i servizi interessati possono utilizzare le risorse inattive (cali) in altre attività o progetti, o, al contrario, possono destinare risorse aggiuntive (picchi). Cioè, è possibile usufruire della flessibilità, ma questa flessibilità - soprattutto nel caso dei "picchi" - è più teorica che reale.

Project Manager o Responsabile di Progetto, è una persona, con livello dirigenziale - sia presso l'organizzazione di sviluppo, sia presso l'organizzazione informatica, sia funzionale che centrale - con le stesse responsabilità di base del "Project Leader", ma con alcune differenze fondamentali.

Prima di tutto deve avere, almeno per il progetto, la gestione delle persone - specificamente nominate - che lo svilupperanno e che, logicamente, provengono da diversi gruppi e dipartimenti. Questo gli conferisce maggiore capacità decisionale e di manovra durante tutto lo sviluppo, anche se la nomina dei membri del team non è facile e spesso presenta alcune difficoltà.

In secondo luogo, avendo maggiore autorità delegata, ha una maggiore responsabilità nella gestione delle risorse umane e nel rispetto degli impegni del progetto.

Questo tipo di organizzazione (con un "Project Manager") può essere appropriato per lo sviluppo di progetti multifunzionali o progetti specifici (generalmente tecnici) o insiemi di piccoli progetti di miglioramento relativi ad applicazioni specifiche. In questi casi, questa responsabilità può essere assunta da un direttore dell'organizzazione di sviluppo o dell'organizzazione informatica centrale.

Questa organizzazione ha il vantaggio fondamentale di avere una responsabilità unica, sia per la funzione che per la direzione utente.

Come mostrato, a seconda del tipo di progetto in questione e della maturità organizzativa della società o organizzazione informatica, si può focalizzare la responsabilità per lo sviluppo in forme differenti, anche se nessuna di esse esonera ciascun dipartimento dall'esercizio delle proprie responsabilità (funzione utente, analisti funzionali e sviluppatori), né esonera la direzione informatica dal coinvolgimento e dal controllo.

Gestire l'attuazione del piano

Il monitoraggio e il controllo più ricchi di informazioni sono senza dubbio le riunioni periodiche, di solito mensili, in cui si presentano i rapporti di progetto, documentando la situazione attuale rispetto a quella prevista e, quando ci sono deviazioni, spiegandone le cause e proponendo piani d'azione alternativi - tra i quali si sceglie e si raccomanda - per recuperare il divario tra piano e situazione attuale.

Queste riunioni sono presiedute dal CIO o dal direttore dello sviluppo, cui partecipano i direttori e talvolta i professionisti più importanti sia del dipartimento di sviluppo che dei dipartimenti informatici funzionali. Può anche assistere il direttore della funzione utente. Normalmente, una copia del verbale viene inviata alla persona o all'ufficio del segretario del comitato di redditività (vedi cap. 4.1) per consentire il monitoraggio del piano.

In tali riunioni, convocate dal direttore dello sviluppo, si esaminano i progetti più critici o problematici in modo più dettagliato, ma si dà anche una visione d'insieme degli altri progetti.

Naturalmente, ci possono essere anche altre riunioni di revisione, su richiesta dei dirigenti, che spesso riguardano un progetto specifico.

Un altro modo per controllare e supportare i progetti che le circostanze giustificano o richiedono, sono le revisioni tecniche, generalmente svolte da altri professionisti della stessa azienda o organizzazione che analizzano e risolvono i problemi tecnici che si presentano nello sviluppo al fine di evitare o correggere deviazioni, soprattutto in termini di risorse consumate o per l'eventuale spostamento della data di completamento.

In molti casi, queste revisioni tecniche sono spesso richieste nelle riunioni di monitoraggio mensile o su iniziativa dei "Sistemi di Controllo" (la cui responsabilità è descritta nella sezione 5.1.4.2) e realizzate da professionisti del Centro di Supporto allo Sviluppo (che discuteremo anche di seguito), o anche da professionisti esterni all'azienda o ente.

È chiaro, infine, che queste riunioni periodiche di cui sopra devono avere un supporto di elaborazione a disposizione dei partecipanti e in cui il relatore si basi, con dati aggiornati, per la revisione del progetto.

Finora abbiamo visto il controllo dei progetti durante tutto il loro sviluppo, ma dobbiamo anche sapere, una volta che il progetto è completato, una volta che è diventato un'applicazione in produzione, qual è il risultato effettivo rispetto al piano della sua fase di sviluppo. Questo serve, da un lato, a convalidare e confrontare la stima (sforzi, requisiti, ecc.) fatta prima di iniziare e rivista dopo l'analisi funzionale, e, dall'altro, a evitare gli stessi errori o migliorare alcuni criteri per il futuro, attraverso l'analisi delle possibili cause ed effetti.

Le migliori basi per un'analisi "a posteriori" sono i dati numerici, che permettono un confronto con altri progetti - passati e presenti -. Questi indici, logicamente, devono essere ottenuti in modo omogeneo, per garantire la validità del confronto e fornire una base per proiezioni future di ottimizzazione.

Questi indici numerici dovrebbero basarsi su una singola unità di misura. Quella che abbiamo sperimentato, chiamata Function Point (Punto Funzione), sarà analizzata nella Parte 3ª - Risorse -.

Ci sono altre unità di misura utilizzate in alcune società o enti che sono generalmente basate sulle "migliaia di righe di codice". Questa misura si applica a progetti di milioni di linee (ad esempio i sistemi operativi), ma nella gestione dei progetti normali presenta una grande diversità - o mancanza di accordo - sui criteri da seguire per la misurazione delle linee di codice: si contano le linee sorgente o oggetto? Hanno lo stesso valore in un linguaggio di alto livello che in un linguaggio base tipo Assembler? Vengono conteggiate come righe le istruzioni di controllo del codice per l'esecuzione in produzione? ecc. Non sorprende che, a causa di queste disparità, non sia possibile confrontare le aziende.

È anche discutibile il criterio di misurazione della produttività basato sulle linee di codice: ad esempio, è più produttivo un programmatore che utilizza dieci istruzioni per una semplice somma o uno che utilizza la stessa quantità per un'istruzione complessa?

Ebbene, basandosi sulla misura dei punti funzione (si veda il Capitolo 17), si derivano misure importanti come:

• Produzione totale: Punti Funzione prodotti al mese o all'anno.
• Produttività: Punti Funzione / uomo x mese.
• Qualità: "Difetti" / Punto Funzione.

Un'altra misura è l'"on-target", che è l'insieme di tutti i progetti realizzati che rispettano gli impegni di data e costo delle risorse umane coinvolte.

Queste misure saranno approfondite nella Parte 3ª - Risorse -.

In ogni caso, si dice che quando un progetto viene completato in tempo e svolge le funzioni incluse nella sua fase di requisiti, alla funzione utente, da parte della società o dell'ente, vengono attribuiti i risparmi promessi nel "Business Case" davanti alla commissione o organo di redditività (capitolo 3).

Come sostenere l'attuazione del piano

Il supporto che discuteremo riguarda gli aspetti tecnici o professionali relativi alle attività che porteranno all'attuazione del piano, e per supportare la gestione al livello tecnico richiesto.

Queste attività riguardano le tecniche di:

• Analisti funzionali, che, come abbiamo detto, possono appartenere gerarchicamente alle funzioni utente e funzionalmente alla direzione centrale dello sviluppo. Questa relazione funzionale supporta le attività delle fasi di requisiti e analisi funzionale.

Centro di Supporto allo Sviluppo

La responsabilità primaria del dipartimento è quella di supportare la ricerca, selezionare, imparare, insegnare e risolvere i problemi derivanti dall'utilizzo di nuovi strumenti tecnici, controlli, metodologie, prodotti, ecc., per contribuire a raggiungere il livello di eccellenza in tutte le attività di sviluppo.

Nell'ambito dei compiti di assistenza tecnica, questo dipartimento aiuta a migliorare la produttività e la qualità degli sviluppatori in aree quali l'analisi degli errori ripetuti nei test (utilizzando, ad esempio, tecniche note come "diagramma di Ishikawa" e/o Pareto), l'ottimizzazione delle sequenze di test interrotte da errori (il cosiddetto "test di regressione"), l'organizzazione per l'uso di codice riutilizzabile, e così via.

Anche il supporto deve essere progettato per affrontare sia lo sviluppo che le funzioni utente, in termini di risorse umane adeguatamente formate in ciascuna organizzazione. A questo proposito, le risorse umane delle funzioni utente in relazione allo sviluppo dipendono dal grado di meccanizzazione della società o ente, e quindi il loro numero è variabile.

Un modo per valutare, anche se elementare, il grado di meccanizzazione è quello di confrontare gli sforzi previsti per i progetti di miglioramento con quelli previsti per altri progetti.

Se i primi (miglioramenti) sono inferiori a quelli degli altri progetti, allora il grado di meccanizzazione, in linea di principio, non è molto alto. In questo caso gli analisti funzionali dovrebbero rappresentare tra il trenta e il cinquanta per cento delle risorse umane dello sviluppo (analisti e programmatori).

Se, tuttavia, gli sforzi programmati per i progetti di miglioramento sono pari o superiori a quelli per i progetti di sviluppo, potremmo dire che il grado di meccanizzazione della società o organizzazione è alto o molto alto, nel qual caso le risorse umane dedicate all'analisi funzionale dovrebbero essere considerevolmente ridotte.

Gli obiettivi primari del dipartimento di supporto per il piano di sviluppo dovrebbero mirare all'ottimizzazione delle risorse umane e all'eccellenza delle attività da svolgere, dal momento che, per gli utenti e per la società in generale, l'organizzazione di sviluppo è una sorta di "monopolio" a cui devono rivolgersi per le loro esigenze informatiche.

Questo servizio di assistenza allo sviluppo dovrebbe anche curare la creazione e il controllo del rapporto tra gli sviluppatori e il loro "cliente diretto" (cioè il cliente immediato nel collegamento successivo della catena dei servizi), che è il centro di elaborazione o esercizio.

Queste relazioni sono bidirezionali per lo sviluppo e l'esercizio, perché in un certo senso, gli sviluppatori forniscono il prodotto o il progetto all'esercizio, ma nella direzione opposta, il dipartimento o organizzazione di esercizio fornisce le risorse hardware e software necessarie agli sviluppatori per svolgere il loro lavoro.

Pertanto, è importante raggiungere accordi di servizio, gestiti dal dipartimento di supporto allo sviluppo e dall'esercizio, in cui siano stabilite le caratteristiche e i livelli di servizio che lo sviluppo dovrebbe ricevere dall'esercizio.

All'interno di questo accordo di servizio - che deve essere rinnovato, come un contratto, quando le condizioni cambiano - ci devono essere "clausole" riguardanti: l'indipendenza degli ambienti di test e manutenzione, la capacità della macchina (elaborazione, archiviazione e altre caratteristiche), i tempi di risposta degli editor, delle transazioni, dei processi batch, ecc., il programma di manutenzione e le interruzioni pianificate, la disponibilità del servizio sui terminali, il numero massimo di interruzioni di servizio, ecc.

Il servizio di assistenza deve controllare il rispetto dell'accordo di servizio e supportare lo sviluppo nell'affrontare le eccezioni.

Questo dipartimento, oltre a fornire supporto alla direzione, al livello opportuno (in presentazioni, riunioni, corsi, ecc.), coordina e promuove l'uso delle piattaforme tecniche, dei metodi e degli strumenti che i vari professionisti continueranno a utilizzare, come descritto.

L'origine normale dei componenti del centro di assistenza o supporto allo sviluppo è spesso il dipartimento di sviluppo e la sua dimensione può variare tra il cinque e il dieci per cento degli analisti e programmatori.

Sistemi di Assicurazione o "Garanti della Qualità e del Controllo"

Le persone che svolgono il ruolo di Sistemi di Assicurazione (in alcuni casi sono indicate come "Project Assurance"), che noi chiamiamo "Garanti della Qualità e del Controllo", hanno il compito fondamentale di essere i sindaci o revisori della qualità del processo di sviluppo, al fine di assistere i professionisti coinvolti e la direzione, attraverso misurazioni e controlli interni.

Questa importante funzione o ruolo ha il seguente inquadramento:

• Deve essere indipendente dagli sviluppatori (analisti funzionali, analisti e programmatori) e la sua catena di comando può essere il responsabile dell'organizzazione di sviluppo centrale, o il CIO della società o ente. Nella nostra esperienza, si consiglia, in linea di principio, che dipenda dal direttore dello sviluppo, come garante del processo di sviluppo.
• Il numero di persone che svolgono questa responsabilità deve essere ridotto, e si consiglia di non superare il cinque per cento di tutti gli sviluppatori.
• I suoi membri devono avere una formazione tecnica ed esperienza nella gestione e nel project management. Pertanto, la responsabilità è alta, anche se non hanno responsabilità di gestione delle persone (potrebbe essere una posizione precedente a quella di direttore di una parte dello sviluppo).

Per quanto riguarda le loro aree di azione, possiamo separarle in due gruppi: processo di sviluppo e supporto alla direzione.

Per quanto riguarda il processo di sviluppo, i Sistemi di Controllo o di revisione (audit) dovranno valutare i seguenti aspetti:

• La validità e la coerenza delle previsioni di progetto, prima e dopo il passaggio dal comitato o organo di redditività. Questo dipartimento dovrebbe essere un buon partner per i responsabili di progetto e deve essere supportato sia dal loro prestigio professionale che dal sostegno della loro direzione.
• I rischi dei progetti durante tutto il loro sviluppo. Per fare questo è necessario disporre di una procedura o strumento che serva a decidere e comunicare, sia a coloro che sono coinvolti che alla direzione, che un progetto presenta un rischio medio-alto. Esistono rapporti di rilevazione che, sulla base di alcuni sintomi, richiedono al responsabile di progetto di completarli. Una volta esaminato e valutato questo rapporto da parte dei Sistemi di Assicurazione, si decide la valutazione del rischio, la si comunica, si inizia la procedura da seguire e se ne controlla l'evoluzione fino alla scomparsa del rischio o alla sua riclassificazione a rischio basso o nullo.
• La conformità ai controlli stabiliti dalla metodologia di sviluppo. Per fare questo, i Sistemi di Controllo devono:
  • Partecipare alle revisioni mensili dei progetti, o almeno avere una copia del verbale.
  • Intervenire, validare ed essere il custode dei documenti firmati dagli interessati, per autorizzare il passaggio da una fase di sviluppo alla successiva (queste fasi sono descritte nei processi della Parte 2ª).
  • Garantire che gli aspetti di "sicurezza informatica" e "verificabilità delle applicazioni" non solo siano stati presi in considerazione nei progetti di sviluppo, ma che siano stati implementati e testati in modo corretto (questi importanti concetti sono spiegati nei processi della Parte 2ª).
• Che il prodotto finale, cioè l'applicazione, abbia la qualità richiesta, nel senso che svolga le funzioni o soddisfi le esigenze espresse dall'utente/proprietario nella sua proposta. Questo fa parte del corretto completamento e della firma delle fasi di sviluppo che sono state approvate come garanzia per evitare sorprese alla fine, come "questo non è quello che l'utente voleva", il che crea situazioni difficili e, soprattutto, uno spreco di sforzi e costi in modo improprio.

Per quanto riguarda il supporto alla direzione, come seconda area di attività dei Sistemi di Assicurazione, si concretizza nel supporto che la direzione riceve nel processo di sviluppo nei seguenti aspetti:

• Consulenza alla direzione per l'eventuale istituzione di obiettivi numerici da raggiungere, come la produttività (Punti Funzione / uomo x mese), la qualità (Difetti / punto funzione), l'"On-target" (rispetto di data e sforzi programmati), il totale degli sforzi indiretti, l'avanzamento delle fasi di outsourcing, il costo della qualità (costo delle correzioni dei difetti e il loro numero), l'efficacia e la maturità complessiva del processo di sviluppo (attraverso l'autovalutazione annuale dell'organizzazione, ecc.).
• Consulenza alla direzione anche sui piani d'azione per raggiungere e migliorare gli obiettivi numerici stabiliti, in particolare l'efficacia o la maturità, in quanto include tutti gli aspetti, anche se non in modo specifico.
• Questa consulenza o assistenza in merito ai piani si riferisce non solo alla loro definizione, ma anche al controllo della loro evoluzione, all'individuazione degli scostamenti, alla validazione del completamento e alla verifica che gli effetti dei miglioramenti siano in linea con quelli programmati.
• Traccia l'evoluzione di ciascuno degli obiettivi, identifica le tendenze e fa una prima analisi degli stessi da convalidare o modificare da parte della direzione, per elaborare piani adeguati.
• Garantisce l'esistenza di un programma per migliorare la qualità del processo di sviluppo.
• Le persone dei Sistemi di Assicurazione, svolgendo una sorta di controllo interno o di consulenza continua, fungono da collegamento con le organizzazioni esterne, sia con i revisori esterni alla società o ente, sia assicurando la partecipazione delle altre organizzazioni della società (Utenti, Direzione, Sviluppatori, ecc.) nel processo e nelle fasi di sviluppo.

Manutenzione

Analizzeremo e chiariremo, data la sua importanza, una delle attività descritte per gli analisti e programmatori interni nella sezione 5.1.4: la manutenzione.

La manutenzione in generale è un concetto poco chiaro, che viene molto usato e abusato e contribuisce - a tutti i livelli - a confondere gli sviluppatori nel loro buon operato. Si dicono cose come che consuma l'ottanta o novanta per cento delle attività di sviluppo, che è il cancro che invade e fa crollare lo sviluppo, ecc.

La prima cosa che vogliamo analizzare, per chiarire il concetto, sono i diversi tipi di manutenzione:

• Perfettiva. È quella che migliora o estende ciò che fa un'applicazione in produzione. Questo di per sé è un miglioramento, e come tale deve essere trattato, cioè deve essere un progetto. Essendo in genere piccoli, dovrebbero avere la massima redditività (o il più breve tempo di ammortamento, cioè il RI deve essere uguale o inferiore a un anno). Pertanto non deve essere considerato manutenzione e dovrebbe produrre benefici.
• Adattiva. È quella che riguarda le modifiche da effettuare in una o più altre applicazioni, come risultato di un nuovo progetto di sviluppo. È possibile e anche comune che nell'analisi dei requisiti di un nuovo progetto (o di un aggiornamento) si renda necessaria una modifica di alcune applicazioni che sono in produzione. Il concetto è chiaro: i costi del progetto che ha causato le modifiche devono includere il costo per apportarle, e, quindi, devono incidere sul suo "business case". Ciò è come, in un altro ambito, il budget per la pavimentazione di una strada, che deve includere il costo per elevare il livello del drenaggio e dei cordoli, se necessario, affinché il resto dei servizi pubblici continui a funzionare come prima della pavimentazione. Quindi non dovrebbero essere inclusi nel capitolo costi di manutenzione.
• Correttiva. Questa è la manutenzione, ed è definita come ciò che si deve fare o spendere per le applicazioni in produzione affinché:
  • Continuino a funzionare "come prima".
  • Continuino ad avere la stessa "efficacia" rispetto al passato, ad esempio, che il tempo di risposta non si degradi.
  • Nel complesso, ritornino allo stato in cui erano.

Il costo per procedere a qualsiasi definizione di quest'ultima è il costo di manutenzione, e le cause sono solitamente dovute a un difetto in qualche fase del ciclo di vita del progetto che ha portato all'applicazione che deve essere mantenuta.

Questo costo non produce alcun beneficio aggiuntivo, perché il beneficio è nel tempo impiegato per far funzionare l'applicazione, e deve essere, come abbiamo detto, strettamente controllato perché rappresenta uno sforzo "a perdere".

In ogni caso, applicando correttamente i test, non si può parlare di cifre impressionanti come sforzi "a perdere" molto elevati. Tipicamente, questo costo non dovrebbe superare il quindici per cento del totale speso per lo sviluppo.

Alternative: Outsourcing

Cominciamo col dire che l'outsourcing potrebbe essere la scelta, temporanea o permanente, di una società o ente, basata su una decisione della direzione, di avere solo un piccolo nucleo informatico interno ed esternalizzare l'intero processo di sviluppo (potrebbe riguardare anche i processi di esercizio).

Normalmente questo non è il caso più frequente, tra l'altro, perché il mercato non offre molto alle aziende che gestiscono sia lo sviluppo che l'esercizio (aziende di "data center", "service bureau" e le cosiddette aziende di "outsourcing" o "esternalizzazione").

È anche il caso, con una certa frequenza, che la società che richiede o ha bisogno di realizzare il piano dei progetti di sviluppo, non ne abbia le risorse umane e tecniche perché sono concentrate in un'altra società, controllata o "sorella" dello stesso gruppo o conglomerato di imprese, che è sia il richiedente dei servizi (di cui possono essercene diversi) che il fornitore degli stessi. Questi casi non li consideriamo outsourcing (in realtà sarebbe la fornitura di servizi da parte di società del gruppo stesso), ma il concetto di esternalizzazione che discuteremo si riferisce a quando l'azienda ha esigenze di sviluppo che richiedono più risorse umane di quelle che possiede.

L'outsourcing di sviluppo si verifica solitamente, come alternativa e complemento all'attuazione del piano, quando una società o organizzazione, per realizzare il piano dei progetti approvato, non dispone di risorse umane sufficienti e, allo stesso tempo, ha bisogno di realizzarlo (composto, si spera, da progetti redditizi e urgenti).

L'outsourcing dovrebbe basarsi principalmente sulla premessa che ciò che si appalta non costi più di quanto costerebbe farlo con risorse proprie. Questo porta a considerare che ciò che si intende appaltare, indipendentemente dalla modalità, deve essere stimato in precedenza sulla base di ipotesi di realizzazione con risorse proprie della società o ente appaltante, se del caso.

In questo modo, e solo allora, l'appalto sarebbe vantaggioso per l'azienda sia per il costo (che è uguale o inferiore a quello che avrebbe sostenuto facendolo internamente), sia per i tempi in cui l'applicazione sarà disponibile (poiché conta su risorse aggiuntive).

Dato questo approccio, l'azienda può affrontare il problema in tre modi: con la modalità chiamata chiavi in mano, con l'assunzione e con i contratti a compiti.

L'appalto o subappalto, come preferiamo chiamarlo, chiavi in mano consiste nell'affidare (un progetto o una serie di progetti interconnessi) a un'altra società per un prezzo fisso e con quasi nessun coinvolgimento della società appaltante.

Questa modalità, come ogni altra che discuteremo, è appropriata per alcuni casi o in determinate circostanze e ha i suoi vantaggi e svantaggi, che spesso interagiscono con le sue caratteristiche.

La caratteristica principale di questo approccio è che il progetto, o gruppo di progetti, sia ben definito, almeno a livello di requisiti. È anche molto necessario che l'analisi funzionale sia coerente con i requisiti e, se possibile, supportata da uno strumento tecnico disponibile sul mercato.

È auspicabile che il progetto abbia pochi collegamenti o "interfacce" con le altre applicazioni esistenti, e ancor meno con altri progetti in sviluppo.

In questo tipo di contratto, di solito l'ambiente di test (hardware e software) è quello dell'appaltatore (ed è essenziale che sia pienamente compatibile con quello dell'appaltante), ma è anche possibile concordare che questo ambiente sia quello dell'appaltante.

Inoltre, con questo metodo devono essere trasferiti all'appaltatore tutti i set di dati di test con cui si accetterà il funzionamento o l'applicazione oggetto del contratto.

L'adempimento di queste condizioni o caratteristiche è solitamente molto difficile, e richiede da parte dell'appaltante un notevole impegno, maturità e fermezza di criteri, non essendo insolito che questo renda la modalità di appalto meno attraente.

Un inconveniente è, in linea di principio, vogliamo sottolineare che qualsiasi modifica o variazione dei requisiti comporta, immediatamente, naturalmente, un aumento dei costi per l'appaltatore. Normalmente la questione per la società appaltante, in caso di aumento dei costi, è tra accettare o continuare sulla base dei costi iniziali, non conformandosi ai requisiti nuovi o modificati.

Questo inconveniente è allo stesso tempo, e paradossalmente, il vantaggio di conoscere il costo che rimane invariato se ci sono modifiche alle specifiche utente (requisiti) o funzionali o alle interconnessioni con altri progetti/applicazioni.

Questo tipo di contratto non appare, in linea di principio, molto applicabile alle prime fasi di sviluppo (requisiti e analisi funzionale) perché non è possibile dare un prezzo fisso per qualcosa la cui estensione e complessità sono sconosciute. Se una società o organizzazione desidera appaltare queste fasi, sembra logico ricorrere a un'altra modalità di appalto.

Infine, delineiamo l'importanza della manutenzione, sia per i miglioramenti che per la correzione degli errori. La società che appalta con questo metodo dovrebbe prevedere come intende affrontare questo problema per evitare di non essere in grado di farlo con le proprie risorse, né di essere obbligata o costretta (senza averlo pianificato e valutato) a continuare a farlo con la stessa società che ha svolto lo sviluppo. Una forma, di uso comune, è quella di ricevere una documentazione formale e dettagliata, controllandola ulteriormente, per consentire e facilitare, in un modo o nell'altro, le modifiche future.

La seconda modalità di appalto di cui sopra, cioè l'assunzione, si basa sull'integrare le risorse interne con altre esterne (appaltatore) per realizzare il piano.

In realtà è il modo più semplice e comune di affrontare il problema dell'appalto. È anche quello più offerto, con variazioni più o meno significative in termini di mera assunzione di professionisti con diverse qualifiche, o il noleggio di un team, con o senza capo team, e così via.

In questa modalità i professionisti dell'appaltatore vengono in genere installati presso la sede della società o ente appaltante e condividono l'ambiente di test, per il quale devono conoscere gli strumenti tecnici da utilizzare in tale ambiente. Questa "convivenza" di solito produce effetti positivi sulla produttività. Il costo, di solito, è quello di dover pagare - e in modo produttivo - quelle ore o giorni che non sono stati molto produttivi perché l'impresa appaltante ha rallentato il ritmo di sviluppo per qualsiasi motivo (modifiche, ri-analisi, o a causa di circostanze impreviste, malattia, viaggi, corsi e altre emergenze, ecc.). Inoltre, dobbiamo anche tenere a mente che in tempi di picco di carico, l'impegno supplementare richiesto rappresenta un costo aggiuntivo.

Questo tipo di contratto ha lo svantaggio che di solito non garantisce "a priori" il costo che sarà pagato all'appaltatore perché le possibili fluttuazioni del ritmo generate dall'appaltante possono "contaminarlo". L'appaltante, a sua volta, può avere la tendenza a "informalizzare" le procedure e gli impegni indotta dal fatto di avere più risorse. L'appaltante ha anche la tentazione di diversificare l'appaltatore in altre attività, o anche in altri progetti per i quali non è stato stipulato alcun contratto (stiamo ipotizzando che l'appalto sia specifico per ogni progetto). Se l'appaltante cadesse nell'errore di questa dispersione, il controllo dei costi del progetto sarebbe quasi impossibile.

Ci sono circostanze, come la capacità tecnica e l'esperienza dell'appaltante o la disponibilità di risorse, unite alla pressione del tempo e alla necessità di completare i lavori (l'appaltante), che rendono questo tipo di contratto il migliore e più flessibile.

Terzo e, infine, discuteremo l'appalto a compiti.

Crediamo che sia la forma più evoluta di contratto, ed è dove abbiamo avuto più e migliori esperienze.

Per affrontare questo tipo di appalto è necessario avere controlli e procedure ben definiti e stabiliti da seguire nel processo di sviluppo, in quanto devono essere praticati dai professionisti dell'azienda o ente appaltante e devono essere conosciuti e, di conseguenza, a carico dell'appaltatore.

Nel contesto della decisione di impegnarsi in qualsiasi forma di appalto dovrebbero essere prese in considerazione alcune caratteristiche, quali:

• Conoscere "a priori" i costi di sviluppo, realizzati con risorse proprie, per ogni compito da appaltare (come detto sopra). Questo costo, in tutto o in parte, deve essere nel piano annuale corrente.
• Formazione professionale dell'appaltatore sulle procedure, le tecniche e le caratteristiche dell'installazione nell'ambiente di test.
• Avere ben separati gli ambienti di test, manutenzione e produzione, perché, in linea di principio, i professionisti dell'appaltatore non dovrebbero avere accesso a dati riservati, che logicamente si trovano in produzione.

Ebbene, oltre a queste, dobbiamo anche prendere in considerazione altre caratteristiche specifiche di questo tipo di contratto a compiti:

• Dal momento che con questo tipo di contratto i professionisti dell'appaltatore possono lavorare presso i loro locali o uffici, è necessario prevedere l'installazione di due linee di gestione remota (per garantire la continuità del servizio) con la relativa unità di controllo e terminali.

• È molto auspicabile istituire aree o gruppi di progetti che, dal punto di vista funzionale, abbiano una certa consistenza o coerenza. Così queste aree possono essere affidate a terzi che, oltre a professionisti puramente informatici, abbiano professionisti esperti nella gestione specifica di queste aree (ad esempio Finanza, Amministrazione, Personale, servizio post-vendita, ecc.) per svolgere l'appalto e l'analisi funzionale.

Questa diversità nel numero di appaltatori, che in ogni caso non dovrebbero essere eccessivi, comporta meno rischi nell'appalto, e inoltre, avendo una specializzazione per aree, ha il vantaggio di una rapida comprensione della meccanizzazione e informatizzazione di ciascuna area.

• Questo tipo di contratto richiede che l'azienda appaltante non perda il controllo, in modo che se per qualsiasi motivo il contratto venisse interrotto o abbandonato, i propri professionisti dovrebbero essere in grado di gestire almeno la manutenzione correttiva e i miglioramenti delle applicazioni realizzate dagli/con gli appaltatori.

• La tattica è quella di fare un investimento in quella che noi chiamiamo la prima fase di appalto, per recuperarlo nella seconda e terza.

Attraverso un'analisi dettagliata, è stata definita la matrice che ora spiegheremo, che è stata successivamente convalidata e accettata come comportamento medio empirico, essendo stata applicata a più di 200 progetti di media dimensione (tra i 3 e i 18 mesi x persona di sforzo).

Gli elementi di questa matrice sono fattori che, moltiplicati per lo sforzo (persona x mesi) indicato nel piano, danno i nuovi sforzi, sia per l'azienda appaltante che a carico dell'appaltatore e, a loro volta, suddivisi per sviluppatori e analisti nelle varie fasi (che sono le righe).

• Matrice per le applicazioni esistenti. La determinazione dei fattori o elementi di questa matrice tiene conto che la conoscenza di queste applicazioni è maggiore all'inizio, nella prima fase, per i professionisti interni dell'appaltante.

Chiariamo con un esempio come applicare questi fattori.

Supponiamo che nell'attuale piano annuale ci sia un progetto di modifica nelle applicazioni di previsioni di vendita, il cui sforzo di analisi è di 3 M x U e lo sviluppo è di 10 M x U (M x U è uguale a Mesi x Uomo/Persona).

Supponiamo di aver appena deciso di ricorrere all'outsourcing, o di farlo per la prima volta, e supponiamo, infine, che la suite di applicazioni di previsioni di vendita venga solitamente modificata con una certa regolarità, a causa di nuove strategie, nuovi prodotti, nuova organizzazione, e così via.

Applicando la matrice, in fase 1 perché è la prima volta che appaltiamo quest'area, si ottengono le seguenti attività:

• Interne: 3 M x U di analisi e 10 M x U di sviluppo (entrambi sono influenzati dal fattore 1).
• Appaltate: 2,7 M x U di analisi e 10 M x U di sviluppo (i fattori 0,9 e 1 sono moltiplicati per gli sforzi del piano, che sono rispettivamente 3 e 10).

È chiaro che in questa fase iniziale abbiamo esteso il periodo di ammortamento del "Business Case", poiché i costi di sviluppo sono aumentati dell'importo appaltato, perché in questa fase, i professionisti interni stanno aiutando e imparando le applicazioni da modificare.

Se quest'area di business (applicazioni di previsioni di vendita) avesse un'attività informatica non ripetitiva (nuove applicazioni, modifiche, miglioramenti, ecc.), non potendo capitalizzare in futuro (come vedremo), questo investimento nell'appalto, pagato essenzialmente per imparare queste applicazioni, sarebbe inutile in seguito.

Pertanto, prima di procedere oltre, diciamo che questa modalità di appalto è utile per quelle aree in cui l'attività informatica è ripetitiva, che per inciso, sono quasi tutte, quando la società o ente non è profondamente meccanizzata o informatizzata.

Seguiamo l'esempio. L'anno prossimo, o prima, diciamo, per semplicità, che c'è un altro progetto approvato nella stessa area con lo stesso sforzo.

Applichiamo la matrice in fase 2 (poiché l'appaltatore, pur non essendo esperto, dovrebbe conoscere le applicazioni) e otteniamo i seguenti sforzi:

• Interne: 1,8 M x U di analisi e 5 M x U di sviluppo (i fattori 0,6 e 0,5 sono moltiplicati per gli sforzi rispettivi del piano, 3 e 10).
• Appaltate: 2,7 M x U di analisi e 10 M x U di sviluppo (come nella prima fase).

In questa seconda fase, che comincia a essere stabile, si segnalano due aspetti:

Redditività. Il ritorno sull'investimento (ROI) si verifica nello stesso termine approvato nel piano a condizione che il costo complessivo (interno e appaltato) non superi il costo previsto. Per ottenere questo, una volta noto il costo per mese x persona (M x U è la notazione usuale, che significa Mese x Uomo), si deve rispondere dei costi, che:

• 1 M x U di auto-analisi => (0,6 M x U interni + 0,9 M x U appaltati) di analisi e
• 1 M x U di auto-sviluppo => (0,5 M x U interni + 1 M x U appaltati) di sviluppo.

Questo determina il prezzo del mese appaltato rispetto al costo totale di quello interno.

Dispersione. In questa fase, un professionista dello sviluppo della società appaltante (interno) è in grado di coordinare lo sviluppo di due professionisti appaltati. Allo stesso modo, un professionista dell'analisi (interno) è in grado di coordinare 1,5 professionisti dell'analisi dell'appaltatore. Ovviamente, questo arricchisce il contenuto del lavoro dei professionisti della società appaltante, senza perdere il controllo dello stato delle applicazioni informatiche.

Per semplicità, supponiamo che nel terzo periodo ci sia di nuovo un progetto nella stessa area e con lo stesso sforzo. In questo caso, dal momento che l'appaltatore dovrebbe essere consapevole di queste applicazioni, dobbiamo applicare i fattori della fase 3. Così, gli sforzi sono:

• Interne: 1,02 M x U di analisi e 2 M x U di sviluppo (3 x 0,34 = 1,02 e 10 x 0,2 = 2).
• Appaltate: 2,7 M x U di analisi e 10 M x U di sviluppo (3 x 0,9 = 2,7 e 10 x 1 = 10).

Questo terzo stadio è considerato stabile e, come tale, i suoi fattori non si evolvono.

Vediamo come si comportano redditività e dispersione.

Redditività. Come nella seconda fase, il RI avverrà nel periodo specificato nel piano, se complessivamente il co ^s non aumenta. In questa fase è più facile per le condizioni del costo, se inferiore fattori influenzano le risorse proprie:

• Analisi 1 M x M (0,3 M x M x M propri + 0,9 M contratto) l'analisi e la
• 1 M x M auto-sviluppo => (0,2 M x M x M + 1 proprio assunto M) di sviluppo.

Dispersione. Nella terza fase, un professionista di sviluppo in grado di coordinare cinque imprenditore professionale di sviluppo. Inoltre, in questa fase, un professionista di auto-analisi in grado di coordinare professionale 2,6 analisi del contraente.

In questo tipo di Lavori in qualsiasi fase, è importante che ci sono diversi imprenditore professionale in ogni zona (sia in analisi e sviluppo) per impedire, con la mobilità attesi di questi professionisti (altri luoghi della stessa azienda, o di altre società), scompare la conoscenza esistente "solera" delle applicazioni, perché altrimenti, si rischia di tornare al primo stadio con il contraente stesso nella stessa area.

I fattori che si applicano alla nostra professionalità proprio in questa terza fase dovrebbe garantire il controllo e la manutenzione futura delle applicazioni che è stato assunto.

Ora per la matrice di reclutamento per i progetti di riqualificazione. Questa matrice, come indicato, è lo stesso come sopra, eccetto che rende superflua la prima fila, il che è equivalente al primo stadio.

Il motivo è chiaro. La prima fase nella matrice precedente è stato utilizzato in gran parte per l'appaltatore professionale familiarità con i componenti tecnici e la struttura delle applicazioni esistenti. Poiché in questo caso i progetti sono nuovi, il punto di partenza è lo stesso per i nostri professionisti propria e l'imprenditore.

L'applicazione degli esempi di cui sopra è ancora valida, sempre che siano applicabili alla seconda fase e la terza.

"Come assegnare la priorità i progetti IT." DJ Martin Buss, Harvard Business Review Deusto ⁴ febbraio Trim. 1983.