Un progetto di EP può scomporsi nei seguenti passi: individuazione degli obiettivi strategici, studio di fattibilità e stesura dei requisiti, pianificazione, sviluppo, esercizio e evoluzione.

L'individuazione degli obiettivi strategici deve essere condotta all’interno dell’azienda coinvolgendo sia il management sia l'IT manager. Se ai primi spetta il compito di individuare i processi e le funzionalità che possono trarre giovamento e guadagnare in efficienza grazie alla portalizzazione, il settore IT ha il compito di sposare un cambiamento tecnologico che consenta di ragionare in un'ottica distribuita.

Terminata questa fase è possibile rivolgersi a un fornitore che deve aiutare l’azienda a stendere lo studio di fattibilità evidenziando un programma di interventi che, in tempi ragionevoli e con i minori traumi possibili, renda disponibili attraverso l’EP le funzionalità individuate. In questa fase è fondamentale individuare anche un scala di priorità per implementare con ordine le funzionalità richieste.

Il progetto di un EP è complesso perché, come abbiamo visto, coinvolge problemi di tipo funzionale, tecnologico e gestionale.

Una volta individuati con chiarezza i servizi che occorre offrire agli utenti del portale e fondamentale condurre una attenta analisi per individuare le tipologie di utenti stessi che possono accedervi. Tale sforzo sarà apprezzato dagli utenti che potranno accedere ad un ambiente appositamente creato per loro dove troveranno tutti e solo quei servizi inerenti il loro ruolo all’interno dell’azienda.

Detto questo occorre concentrarsi sul progetto che si va a realizzare. Uno dei rischi più comuni è quello di porsi obiettivi troppo ambiziosi o di sottovalutare la situazione complessa ed eterogenea che caratterizza il sistema informativo aziendale, rispetto alle risorse umane ed economiche che si hanno a disposizione.

Proprio per questo il fornitore esperto dovrà, come anticipato, suggerire un percorso per gradi che permetta di partire con la portalizzazione di alcuni servizi di base a cui si aggiungeranno nel tempo nuovi funzioni / processi solo quando saranno stati riorganizzati. Più si riesce a suddividere il progetto dell'Enterprise Portal in sotto micro progetti con un inizio e una fine ben definiti, più sarà facile gestirne lo sviluppo, garantirne il rilascio entro i termini stabiliti e addirittura tornare sui propri passi nel caso ci si sia incamminati in un vicolo cieco. Il rischio dei grandi progetti che vanno online solo dopo decine di mesi, se non anni, di sviluppo è che quando ci si accorge di un errore di impostazione è oramai troppo tardi per porvi rimedio.

Il consiglio è dunque quello di predisporre una opportuna infrastruttura che garantisca un sufficiente margine di flessibilità e poi procedere gradualmente a popolarla con i servizi richiesti. L'agilità e la prontezza di intervento sui progetti è una delle migliori garanzie di riuscita. L'idea dell'EP è quella della costruzione di un bazar contrapposto alla costruzione di una cattedrale. Nel primo caso, una volta individuato lo spazio e costruite le infrastrutture di base, si può procedere a poco a poco popolandolo con le singole bancarelle. Sino dalla prima bancarella è possibile aprire il bazar al pubblico senza che ci siano pericoli di sorta. Ovviamente diverrà sempre più interessante quanto più aumenteranno le bancarelle ma avrà vita propria già dall'inizio. Differente è il caso della cattedrale che fino a che non è terminata (mesi / anni di lavoro)  non potrà essere dichiarata agibile e svolgere la sua funzione.

Il paragone della cattedrale e del bazar è stato preso a prestito, anche in modo non del tutto ortodosso, da un famoso manifesto Linux di Eric S. Raymond che lo ha proposto osservando lo sviluppo del progetto Linux e la propria esperienza di sviluppatore open source. In questo contesto infatti lo sviluppo di un progetto è guidato dalle esigenze della comunità open source che possono notevolmente cambiare nel tempo.

Proprio per progetti di questo tipo negli ultimi anni si fa ricorso sempre più di frequente a differenti modelli di sviluppo del software che stanno sostituendo quello tradizionale a cascata (analisi, progetto, sviluppo, test, rilascio). Tra i più in voga meritano un posto privilegiato le così dette metodologie agili che risultano efficaci nei contesti in cui occorre procedere a piccoli passi, in stretto contatto con il cliente, con una continua serie di piccole implementazioni e veloci rilasci (ad esempio mensili o addirittura quindicinali o settimanali). In questo modo il cliente può testare il software a mano a mano che viene sviluppato e rilasciato e aggiustare il tiro senza compromettere o ritardare in modo significativo l’intero progetto.

Questo modo di operare si applica bene agli EP, dove uno degli elementi critici è la User Experience, cioè la facilità che l’utente ha nel fruire il sito e i servizi che gli vengono messi a disposizione. Va infatti sottolineato come nel caso di EP si rendono disponibili differenti applicazioni che non sono in alcun modo presidiate.

L'utente deve dunque essere in grado, in modo autonomo e spesso senza alcuna formazione specifica, di utilizzare tutte le funzioni/applicazioni messe a sua disposizione. È chiaro dunque che un EP difficile da utilizzare, con interfacce non omogenee e che richiedono sforzi cognitivi e mnemonici agli utenti è una occasione mancata e finirà per generare frustrazione negli utenti che, dopo qualche sforzo iniziale, tenderanno ad non usare più il sistema decretandone la morte. Le metodologie agili consentono un approccio in cui è possibile prototipare velocemente e far testare e usare con mano la piattaforma sin da subito, per lo meno a una parte dei destinatari.

Le principali cause che trasformano quello che sembrava un brillante progetto in un "bagno di sangue" sono da attribuire alla perdita di interesse del top management che, dopo un buon coinvolgimento iniziale, si fa da parte e non partecipa più in modo attivo e propositivo alle varie fasi. La seconda causa di insuccesso è la mancanza di capacità gestionali da parte del fornitore.

Più spesso di quanto si pensi può accadere che il fornitore non sappia cogliere gli elementi chiave del progetto e, soprattutto, non sia capace di descrivere con sufficiente chiarezza quello che si accinge a realizzare in modo che il cliente recepisca e approvi esplicitamente le specifiche. Il bravo fornitore deve riuscire a coinvolgere il cliente per avere la certezza che quanto specificato risponda esattamente alle sue esigenze.

L'ottimismo prematuro è fatale: proprio i clienti che, in fase di progetto e di stesura delle specifiche, sembrano approvare tutto, si rivelano poi, durante lo sviluppo, o peggio ancora alla consegna, fonte di problemi senza fine.

Una volta terminato lo sviluppo della piattaforma di base e delle funzionalità che in fase di pianificazione si sono ritenute prioritarie, e conclusa con successo una adeguata fase di test nell’ambiente di prova, l'applicazione è pronta per il grande passo: il così detto deploy o messa in produzione.

Le criticità di questa fase sono sovente legate ad aspetti sistemistici e di eventuali sottostime dei volumi di traffico da garantire. Per scongiurare il primo problema occorre accertarsi che il proprio fornitore abbia anche skill di tipo sistemistico su tutte le tecnologie coinvolte in modo da risolvere i problemi che possono insorgere. I primi vagiti di un progetto di EP richiedono una cura costante, tanto più qualificata quanto più sono eterogenee le tecnologie e le architetture coinvolte.

Per quanto riguarda invece la scalabilità, è vero che oramai l'hardware, soprattutto in caso di scalabilità orizzontale (vedi anche Scalabilità nel Glossario), ha costi molto contenuti ma occorre aver progettato un software in modo opportuno, ad esempio con una gestione quanto più possibile "leggera" della sessione utente. È questa infatti una caratteristica fondamentale da tenere sotto controllo per non spostare il collo di bottiglia dai server alla rete, che potrebbe venire in breve tempo intasata dal traffico generato dal bilanciamento del carico.

Qualsiasi progetto di EP, soprattutto se riuscito, richiede una costante evoluzione nel tempo: già nella fase di progettazione iniziale infatti si saranno pianificati una serie di funzionalità da rilasciare successivamente al primo deploy.

Sarà dunque importante accertarsi di avere a disposizione (all’interno dell’azienda, in outsourcing dal fornitore o in outsourcing da terzi) le risorse per mantenere sotto controllo l’architettura hardware e software. Oltre alle adeguate competenze chi effettua la manutenzione dovrà dare prova di una adeguata efficienza operativa supportata da un opportuno SLA (Service Level Agreement).

Come si è può vedere, il progetto di un EP è complesso in quanto non si tratta di acquistare un prodotto software (per esempio un Word Processor) o commissionare un applicativo per cui può essere sufficiente limitarsi a passare al fornitore le specifiche (es. gateway di pagamento) ma occorre realizzare e mettere in produzione una "soluzione tecnologica".

È quindi importante che il progetto dell'EP venga sviluppato insieme al fornitore e utilizzato il prima possibile per far sì che si adatti alle esigenze aziendali. Un altro pericolo in cui ci si imbatte è quello di portarsi a casa soluzioni pre-confezionate che richiedono poi un notevole sforzo per essere adattate. Questo tipo di errore può avvenire sia per colpa del fornitore che può essere, ad esempio, legato commercialmente a un'azienda produttrice, sia a causa di IT manager "innamorati" di un particolare pacchetto che si intestardiscono a voler utilizzare nonostante le riserve del fornitore.

(Continua la lettura: a seguire la sezione "Architettura e tecnologie per gli Enterprise Portal")