Sviluppo software in .NET? Ecco il blog giusto!

E’ con piacere che pubblico l’indirizzo di un blog che ha le potenzialità di diventare un punto di riferimento e di scambio, per quanti fanno degli ambienti di sviluppo .NET un uso “quotidiano”  (http://www.MassimilianoSpinettiPMP.info/).

 

Massimiliano amico, socio e collega, anch’egli project manager certificato,  è persona competente, sincera e appassionata.

Caratteristiche che, sono sicuro, riuscirà a trasmettere attraverso i suoi scritti.

Buon viaggio!!!

Agile PM e matrice debole: due mondi paralleli?

In questo post affronto un tema a mio avviso molto interessante: come è possibile conciliare la metodologia agile per sotto-progetti IT,  che supportano progetti di creazione di nuovi prodotti in organizzazioni che lavorano per funzioni?

---

Nel post Influenza delle organizzazioni aziendali nella gestione dei progetti  ho parlato delle differenti tipologie di organizzazioni e del loro approccio nella gestione dei progetti.

Ognuna di esse, attraverso il proprio management, sviluppa nuove idee di business per lo sviluppo di nuovi prodotti o servizi da lanciare e posizionare sul mercato.

Il primo “slancio” creativo, infatti, lo fanno le persone che conducono l’azienda; persone che hanno decisio la  strategia aziendale e che hanno una visione a 360° del mercato in cui opera l’azienda.

Le idee nate, vengono quindi poste nelle mani dei manager di seconda linea (middle management), affinché siano approfondite e concretizzate.

Queste persone ne sviluppano, o fanno sviluppare, studi di fattibilità, analisi sul ritorno degli investimenti (“investment payback period”, ROI,ecc.) stime dei costi, dei tempi e delle tempistiche di lancio.

Quest’ultima per verificare l’effettivo inquadramento del prodotto sul mercato, all’interno delle finestre temporali richieste dal management; periodo in cui si presuppone di massimizzare la profittabilità dell’azione svolta.

Questa fase di assesment dell’idea (tempi/costi/benefici), porterà alla selezione di quei progetti più convenienti per l’organizzazione.

 

Gli stessi manager che hanno terminato questa fase, probabilmente diverranno gli sponsor dei singoli progetti incaricati di rilasciare i prodotti sul mercato. Loro sceglieranno, o dovrebbero scegliere, i project manager adatti a prenderne la guida e forniranno loro, tutte le informazioni raccolte e le risorse necessarie allo svolgimento del progetto stesso.

Coinvolgimento del dipartimento IT

Ogni progetto fa uso di notevoli quantità di dati e necessita di strumenti adeguati di comunicazione, che obbligano di fatto  il coinvolgimento del dipartimento IT (Information Technology) o IS (Information Systems).

Tale dipartimento, infatti, dovrebbe fornire al project team gli strumenti adatti per la conduzione del progetto, come per esempio:

• Sistemi per lo scambio di Email
• Instant Messaging Systems (es. Messenger, Skype, ecc.)
• Attrezzature per phone/video conference
• Intranet dedicate per la pubblicazione e centralizzazione dei documenti di progetto
• Software di project management

In molti casi, però, il prodotto in fase di progettazione, necessiterà dello sviluppo di procedure software dedicate, ospitate su opportuni sistemi hardware e di rete. Responsabilità, quelle, ancora in carico all’IT.

Il progetto di fatto potrebbe essere suddiviso in due distinti sotto-progetti.

Il primo legato all’area prettamente “business” dell’idea, e che dovrebbe produrre documentazione, modelli e studi, che porteranno alla concretizzazione del progetto nel prodotto/servizio.  Il secondo, a supporto del primo, si occuperà di implementare procedure software, processi, flussi dati e workflow, governando anche le tematiche più prettamente sistemistiche.

E’ in questo momento che possono insorgere problemi tra i due line/functional manager (project manager e responsabile IT), che si trovano a dipendere l’uno dall’altro per la buona riuscita del progetto nella sua totalità.

La prima considerazione riguarda le differenti aree lavorative delle persone coinvolte e il loro differente approccio al lavoro.

Il pm, figura spesso prelevata dall’area di business o funzione aziendale interessata dal progetto, ha spesso un approccio molto “macro” al problema, conosce piuttosto bene il mercato, ha una visione ad alto livello del contesto progettuale, dei vincoli, delle limitazioni e delle opportunità.

Potrebbe in effetti, non parlare  un linguaggio tale da riuscire a trasmettere le informazioni all’IT, con la giusta granularità, precisione e minuzia proprie delle necessità ”informatiche”.

Dall’altra parte il responsabile IT: di probabile estrazione tecnica, necessita appunto di informazioni dettagliate (micro) sui processi e sulle procedure da implementare.

Deve capire i processi coinvolti, conoscere natura e tipologia dei dati, algoritmi di calcolo, corrispondenza tra informazioni di input e output, visibilità dei dati e modalità di trattamento. Le informazioni fornite, dovrebbero anche metterlo nelle condizioni di percepire eventuali possibilità di astrazione dei processi, al fine di renderli generalizzati e riusabili per successive necessità con un conseguente risparmio di denaro.

La seconda considerazione riguarda invece le criticità legate al fattore tempo e alle conseguenze che ne derivano,

Mi spiego meglio. Può accadere che un progetto di importanza vitale per l’azienda, venga lanciato in tempi brevissimi, senza avere a disposizione i piani e i documenti analitici di riferimento, requirements e business case,  budget solo accennati, risorse necessarie non sempre disponibili,  descrizione mancante della qualità necessaria.
L’unica cosa certa è appunto il vincolo tempo: la data di consegna è già decisa.
Questa situazione è paradossale, se consideriamo che è solo in funzione della pianificazione dettagliata di cosa deve essere fatto (WBS + scomposizione attività + stime tempi + stime costi) e con quali risorse, sarà possibile fissare una data di rilascio.

Il project manager, quindi, si trova a dover dialogare con il responsabile IT, non avendo a disposizione informazioni di dettaglio sufficienti per poterlo attivare nel migliore dei modi.

Come fare allora?

Come conciliare i mondi “micro” e “macro” delle due figure?

Come gestire la mancanza di dettaglio analitica del progetto?

 

A mio parere si dovrebbe lavorare su diversi livelli.

Innanzitutto si dovrebbe colmare la distanza di “comunicazione” tra il mondo business e il mondo IT, al fine di rendere più facile e veloce la successiva stesura dei piani analitici necessari.

Si procederebbe quindi alla definizione degli obiettivi strategici da perseguire con il progetto e per questi procedere alla definizione  di un buon livello di dettaglio degli stessi.

Affidarsi all’agile project management e allo sviluppo iterativo, affinche sia possibile sin da subito, cominciare con lo sviluppo delle funzionalità a maggiore priorità.

Utilizzare infine, la tecnica roll wave planning  per condurre in parallelo fasi analitiche dettagliate delle funzionalità  da sviluppare nelle prossime iterazioni.

Nel prossimo post, illustrerò con maggior dettaglio, una possibile soluzione…..ecco un esempio di roll wave planning!

Stay tuned

Articolo Progetti e Qualità

Pubblico un mio articolo apparso sulla rivista DeQualitate di ottobre, in cui parlo dei diversi macro-aspetti che riguardano i progetti e la qualità.

Influenza delle organizzazioni aziendali nella gestione dei progetti

Quanto il contesto aziendale condiziona l’esecuzione del progetto? 

Che difficoltà può incontrare il project manager se lavora in un’organizzazione aziendale strutturata per funzioni invece che per progetti?

---

 

In questi giorni sto conducendo alcune sessioni di corsi di project management in una importante multinazionale che eroga servizi finanziari.

Durante lo svolgimento sono nati spunti di confronto e discussione molto interessanti.

Quelli che sono apparsi più “spinosi” in quel contesto, riguardano il ruolo delle persone incaricate a seguire i progetti, la loro influenza sull’organizzazione e il grado di autorità decisionale che si trovano ad avere.

L’azienda in questione è strutturata per funzioni: organizzazione in cui esiste un functional o line manager per ogni  divisione e in cui lavorano persone che oltre alle attività quotidiane, possono essere incaricate come project leader o come team member per l’esecuzione di progetti.

Progetti che alcune volte sono interni ad un unica funzione aziendale oppure a più ampio respiro, coinvolgendo più funzioni.

Questo tipo di organizzazione, dal punto di vista del PMBOK, è riconducibile al tipo di organizzazione a matrice debole.

Le possibili “configurazioni” identificate dal PMI sono le seguenti:

• Funzionale
• Per Progetti
• Matrice Debole
• Matrice Bilanciata
• Matrice Forte

Tipologia di organizzazioni

 

Organizzazione Funzionale

I progetti in queste aziende vengono gestiti separatamente in ogni funzione, nessuno sharing di risorse tra divisioni differenti e neppure alcun obiettivo comune da perseguire attraverso progetti.

Il project manager non esiste perché il responsabile è il functional o line manager della funzione aziendale in cui si svolge il progetto.

Autorità del P.M.	Nessuna
Disponibilità Risorse	Scarsa
Controllo Budget	Functional Manager
Ruolo P.M.	Functional Manager

 

Organizzazione per Progetti

Organizzazione di questi tipi lavorano per progetti, non per funzioni.

Il project manger ha un elevato grado di autorità e indipendenza decisionale.

I team hanno ottima cultura di project management e i membri degli stessi, sono facilmente intercambiabili gli uni con gli altri.

Autorità del P.M.	Alta
Disponibilità Risorse	Alta
Controllo Budget	Totale
Ruolo P.M.	Full-time

 

Organizzazione Matrice Debole

L’azienda è organizzata per funzioni, ma i progetti possono interessare orizzontalmente più divisioni e quindi includere persone appartenenti a funzioni differenti.

Non esiste un vero project manager, bensì un coordinatore facente parte di una determinata funzione aziendale, il quale fa riferimento al responsabile di quella unità.

Autorità del P.M.	Limitata
Disponibilità Risorse	Limitata
Controllo Budget	Functional Manager
Ruolo P.M.	Part-time

 

Organizzazione Matrice Bilanciata

Struttura identica alla precedente,  il coordinatore, in questo caso project leader, però ha una autorità riconosciuta e con una sufficiente dose di autonomia.

Sebbene la persona appartenga ad una determinata funzione aziendale, il project leader per tutta la durata del progetto non deve rispondere al proprio resonsabile di funzione.

Autorità del P.M.	Media
Disponibilità Risorse	Bassa
Controllo Budget	Misto
Ruolo P.M.	Full-time

 

Organizzazione Matrice Forte

 Queste sono aziende che prevedono una funzione dedicata al project management. A questa funzione appartengono i project manager, ai quali vengono assegnate risorse provenienti da altre funzioni aziendali.

Autorità del P.M.	Moderata
Disponibilità Risorse	Moderata
Controllo Budget	Totale
Ruolo P.M.	Full-time

 

Considerazioni sulla matrice debole

Autorità e risorse a disposizione

Il team leader incaricato del progetto, riceve in “dote” i membri del team con ristrettissime possibilità di scelta o di negoziazione di altre risorse. Tali risorse vengono cedute al progetto per durata ed orari circoscritti e con calendari “difficili”.

Le persone assegnate al progetto, non essendo dedicate completamente allo stesso, rimangono di fatto in carico alla funzione aziendale e a quella funzione devono dare risposte e fornire risultati e solo nel tempo libero (ma quale tempo libero?)  dedicarsi al progetto.

Comunicazioni

Comunicazioni difficili dovute principalmente al fatto che non esiste una “war room” dove il team si incontra e lavora fianco a fianco. I documenti di progetto, le comunicazioni non sono centralizzate, ma vengono condivise attraverso email spedite a tutti i partecipanti.

Questa situazione genera in breve tempo confusione, malintesi e entropia che possono portare i membri del team, alla disaffezione nei confronti del progetto o alla difficoltà di focalizzazione sulle attività in carico ad ognuno.

Performance

Non avere contatti diretti e frequenti con il team, ha impatti sostanziali anche sulle performance.

In situazione normali, infatti, la vicinanza permette al pm di avere riscontri diretti su eventuali problemi  e di ricevere informazioni rispetto allo stato di avanzamento delle attività in carico ad ogni team member. 

Disporre di poche risorse, con disponibilità temporali ridotte, limita notevolmente la possibilità di condurre attività di Earned Value (stati di avanzamento lavori) puntuali e precise che indicherebbero con buon anticipo eventuali ritardi sul pianificato.

Inoltre, non disporre di dati sulle performance impedisce di fatto ai project leader incaricati, di produrre reportistica riugardante stime a finire sia in termini di tempi sia di costi.

Cultura di project management poco sviluppata

Capita che in organizzazioni come queste, non sempre si percepisce la necessità di sviluppare una cultura aziendale di project management.

Questa situazione è rispecchiata direttamente dalle performance dei progetti che spesso ritardano la loro messa in produzione, accumulano costi eccessivi rispetto al pianificato, non raggiungono tutti gli obiettivi prefissati oppure non producono risultati della qualità attesa.

Trend che fortunatamente sta invertendo la rotta, almeno nell’azienda con la quale sto lavorando in questi giorni.

Lì infatti, si sta cominciando a lavorare con convinzione e determinazione in quella direzione.

Sviluppo del team

A seguito di un team “disgregato“ e della poca autorità riconosciuta, è arduo mettere in atto attività di team building, di crescita o formazione del team.

Cosa fare, allora, in quei casi?

Beh, in quei casi anche il singolo può fare molto, considerati i vasti spazi disponibili in azienda in quel campo.

Il primo passo, il più importante, è studiare, informarsi e perché no fare un corso.

Applicare quotidianamente ciò che si è imparato e cominciare ad ottenere qualche risultato positivo, anche piccolo ma che si innalzi rispetto alla media aziendale.

Ecco che allora, diverrete un punto di riferimento per i vostri colleghi e di lì a poco anche il vostro capo comincerà a chiedersi come fate!

…stay tuned!