Ogni progetto è diverso a parità di servizio

Tra i diversi servizi che offriamo, alcuni sono più richiesti rispetto ad altri. Eppure il medesimo servizio, sembra una ovvietà, può avere sviluppi diversi a seconda del contesto.

Ma quali sono alcuni spunti di riflessione sul tema?

Sarà una passeggiata

È capitato di dover affrontare progetti che sulla carta erano in totale discesa. Alcune delle persone con le quali dovevamo collaborare erano già note, il contesto, noto anche quello. Eppure non è andato tutto come ci si aspettava. Difficoltà impreviste, specialmente legate ad aspetti non tecnici. Scontri interni, organizzativi.

Sponsor di progetto a cui non era noto il contesto SAP e tutto quello che comporta. Aver lavorato per anni nell'IT in un determinato ambito può essere sicuramente di aiuto ma può anche portare ad applicare ragionamenti di un determinato contesto in altro (non sempre applicabili). 

La modalità di lavoro

Perché in alcuni casi, a parità di volumi, una attività viene svolta occupando una unità di tempo, mentre in altri casi ne servono dieci? Cosa può andare storto in questi casi?

• L'utilizzo di una modalità Agile
• L'eccessiva formalizzazione (spesso applicata a queste tipologie di progetti) come se fossero classici progetti ERP. Nel caso di definizione di un processo, semplificando, disegno come avviene il funzionamento e quando ho terminato la documentazione (Business Blue Print) realizzo etcc. Nei casi di review autorizzativa possono essere migliaia gli oggetti in gioco (transazioni/app/oggetti) non sempre è possibile formalizzare tutto a qualsiasi livello di dettaglio
• Conoscere cosa stai approvando. Alcuni aspetti sono tecnici e non sempre gli interlocutori hanno la conoscenza adatta per comprendere appieno
• Nel contesto di un progetto più ampio gli aspetti autorizzativi possono essere i primi a subire "tagli" con conseguenti scelte sul progetto
• Può essere davvero complesso considerare tutti gli scenari possibili, specialmente nei volumi di combinazioni presenti nella parte autorizzativa SAP. Il costo di voler verificare e testare tutto, prima di un rilascio, potrebbe essere molto più alto e dispendiosi di provare (dopo avere effettuato un minimo di test) il rilascio e sistemare man mano eventuali problematiche minori. Non significa non dover effettuare i test, ma valutare fino a dove potersi spingere senza superare un trade-off accettabile

Cosa può essere utile quindi?

A mio avviso in generale ed a maggior ragione nelle situazioni descritte sopra, prima dell'avvio di un progetto, può essere utile investire qualche giornata nella formazione (workshop) su cosa accadrà durante il progetto.

1. Esistono dei template (acceleratori). Vantaggi e Svantaggi
   
   
2. Quali saranno le fasi, quali i documenti da usare e chi sarà coinvolto
   
   
3. Quali i punti di attenzione?
   

    

4. Quali le modalità di test
   
   
5. Chi dovrà decidere cosa
   

Meglio quindi investire poco tempo prima per comprendere il contesto, piuttosto che trovarsi in difficoltà a seguito.

Purtroppo non è sempre possibile specialmente nei contesti dove esistono delle gare di appalto. Anche se è possibile prima di svolgere una gara definire ulteriori passaggi preparatori da parte del cliente che si trova in questa situazione.