Come puoi far funzionare un progetto aumentando il budget?
Quindi stavo leggendo questa risposta e mi è venuta in mente una domanda che ho tenuto per un po 'ma non sono mai riuscito a chiedere.
Se hai un progetto in ritardo con ambito, pianificazione e qualità fissi, dovresti essere in grado di risolverlo aumentando il budget, ma ... come?
È ovvio come la rimozione dell'ambito o l'aumento della pianificazione salverà un progetto fallito. Ma secondo The Mythical Man-Month (e secondo la mia esperienza), l'aggiunta di persone a un progetto già in ritardo renderà il progetto anche più tardi.
Quindi ... esattamente come si potrebbe utilizzare il denaro infinito per salvare un progetto di ambito / pianificazione / qualità fisso?
Risposte
La risposta sarà peculiare al singolo progetto. Secondo la legge di Wallace sulla gestione dei progetti, il compito principale del PM è quello di informare le parti interessate degli effetti di qualsiasi modifica su ambito, pianificazione e qualità.
La tua domanda è percettiva: è il motivo per cui assumono un PM. Un buon PM avrà sempre una risposta "Se ti dessi un budget N% extra, come lo spenderesti? Come miglioreresti l'ambito, la pianificazione o la qualità con denaro aggiuntivo?"
Alcune delle risposte sono nel tuo piano di progetto - hai calcolato la catena critica e percorsi critici alternativi attraverso il piano di progetto - quale di queste alternative è più plausibile con un budget aggiuntivo?
Alcune delle risposte sono in altre domande che hai già sviluppato. Quali sono i tuoi vincoli? Quali scelte hai dovuto fare a causa di scelte di bilancio che sarebbero cambiate se il budget fosse aumentato.
la maggior parte della risposta è nel registro dei rischi / problemi. Quali rischi / problemi potrebbero essere opportunità se avessi un budget aggiuntivo?
cavillo minore; il budget non può far funzionare un progetto. Il budget infinito non crea una probabilità infinita di successo. Il budget è un vincolo e la probabilità di successo del progetto è sempre più determinata dal vincolo più restrittivo. Se il budget è infinito, l'ambito o la pianificazione regoleranno il progetto. Un'auto non può andare se il serbatoio del gas è vuoto, ma non andrà più veloce se il serbatoio è troppo pieno. Se il budget è sufficientemente basso da vincolare il progetto, è facile prevedere come l'aumento del budget migliorerà le probabilità di successo; se il budget è sufficientemente alto, è difficile prevedere in che modo il budget aggiuntivo influirà sul successo del progetto. La formulazione della domanda distrae in qualche modo dai problemi reali. "Come puoi fare in modo che un progetto abbia successo aumentando il budget?"? 2/3 delle volte non puoi, perché il progetto non è vincolato dal budget. Ma questo è un cavillo con la formulazione della domanda.
Budget come vincolo illimitato
Gettare soldi a un costo irrecuperabile non "salverà" un progetto fallimentare, ma se non si allocano risorse adeguate per soddisfare i vincoli di altri progetti, allora un progetto non può avere successo in primo luogo. Ad esempio, se hai tre sviluppatori che gestiscono un processo che richiede sette persone, è improbabile che il progetto finisca in tempo. Aggiungere altri quattro sviluppatori una settimana prima del rilascio del progetto non aiuterà (vedere la legge di Brooks ), ma aggiungere risorse adeguate all'ultimo momento responsabile, concedendo tempo per portare a termine le apparecchiature, i processi e il personale, può consentire un progetto per soddisfare i suoi vincoli di tempo o ambito.
È meglio se ridimensionare il budget in anticipo. Un budget più ampio consente di investire in brave persone, formazione di strutture e competenze, strumenti per migliorare l'efficienza, materiali e attrezzature di qualità superiore, ecc. Il finanziamento insufficiente di un progetto crea un vincolo, ma un budget (di per sé) di solito non è sufficiente abilitatore.
Considera il seguente esempio:
- Dato che il progetto ha una scadenza rigida di 6 mesi da ora (programma fisso),
- E un set di funzionalità non negoziabile (ambito fisso),
- Quando il progetto è pianificato
- Quindi il budget (costo) deve essere adeguato per adattarsi all'ambito e alla pianificazione.
In altre parole, hai tre cursori che si influenzano l'un l'altro. Non puoi bloccarne più di due, ad esempio "Velocità, costo o funzionalità; scegli due!" Più sono vincolati gli altri cursori, maggiore è la flessibilità necessaria nella dimensione non legata.
Se non si regola il vertice del budget per soddisfare i requisiti dei vertici fissi, non si finisce con un triangolo: spesso si finisce con un obiettivo di gestione non finanziato (o sottofinanziato). Una volta che ciò accade, dovresti immediatamente rivedere la visione del tuo progetto per leggere: "Creiamo fallimento attraverso il pensiero magico".
Il triangolo di ferro di costo, ambito, tempo, scegli solo due , è un modello di vincoli di progetto. È un buon modello, ma a volte confonde le persone che pensano di poter lavorare solo su una dimensione, mantenendo le altre due fisse. Se il tempo e l'ambito del progetto sono così vincolanti che nessuna somma di denaro può compensarli, il tuo progetto non avrà successo aumentando il budget. Se ti do un trilione di trilioni di dollari per mandare un altro uomo sulla luna entro domani pomeriggio, non sarai in grado di farlo. Ed è lo stesso con i progetti software.
Se butti i soldi sui problemi troppo tardi o ti aspetti troppo da esso, hai ancora i problemi . Se il tuo progetto è in ritardo e porti soldi troppo tardi, non salverà il tuo progetto. La risposta di Todd copre bene questo aspetto, quindi non insisterò oltre. Quello che voglio sottolineare, però, è il fatto che il denaro è un fattore abilitante. Le cose che sono state "riparate" potrebbero non essere più riparate all'improvviso.
Ad esempio, supponiamo che il tuo progetto consista nell'ottimizzazione di un'applicazione in modo che venga eseguita in modo efficiente su piccole macchine virtuali, utilizzando le risorse hardware in modo efficiente, mantenendo bassi i costi del cloud e consentendo in futuro uno scaling orizzontale più efficiente. Hai identificato il lavoro che deve essere fatto e hai due mesi per farlo (per qualche motivo). Dopo un mese la squadra scopre che molto probabilmente mancherà la scadenza. Non possono ridurre l'ambito perché tutto ciò che è definito lì è necessario affinché tutto funzioni. E non possono spostare la scadenza perché è stata fissata. Quindi porta i soldi. Un sacco.
Puoi coinvolgere più persone, ma così facendo scopri che la legge di Brooks si applica e ora il team pensa che lo saranno anche più tardi. Ma il tempo e la portata sono ancora fissi. Oppure lo sono?
Se prendi i soldi e li metti nei più grandi macchinari virtuali che riesci a trovare, quanti ne puoi trovare, non ti interessa più dell'ambito del progetto. Il tuo mirino fisso improvvisamente scompare del tutto. Dopotutto non era così risolto. La tua applicazione può ora essere un maiale di risorse sul cloud e non ti interessa perché hai i soldi per pagare le bollette.
Quindi in conclusione :
- non sono tre vincoli, scegline solo due. In realtà è un equilibrio di tutti e i cambiamenti in uno influenzano gli altri in qualche altro modo.
- un aumento del budget può salvare il tuo progetto ma solo se applicato al momento giusto e con le cose giuste .
Scope, Schedule e Quality definiscono "cosa" il progetto dovrebbe fornire, tuttavia non definiscono "come" consegnerà. Come affermato in altre risposte, un budget maggiore può consentire di flettere il "Come". Nella mia mente, vedo il "Triangolo d'Oro" più come una "Piramide d'Oro", dove il triangolo di base è formato dai vincoli "Costo, Tempo, Ambito" e l'altezza della piramide definisce la "Qualità". Quindi tutti e quattro sono interconnessi.
È vero che gettare risorse indiscriminatamente su un progetto è raramente efficace, tuttavia se il momento è giusto, più risorse potrebbero essere in grado di portare un progetto in tempo e con qualità. Come? - beh, non esiste un'unica risposta giusta, ma suddividere il progetto in parti più gestibili e allocare le giuste risorse agli elementi giusti del progetto sarà generalmente meglio che semplicemente buttare più sviluppatori nel mix senza ristrutturare il progetto per adattarli.
In alternativa, più fondi possono anche consentire un approccio completamente diverso. Ad esempio, invece di costruire una soluzione internamente per evitare il costo di acquisto di una soluzione costosa ma disponibile in commercio, il denaro extra potrebbe cambiare quella decisione. Fornirai comunque il risultato atteso, ma acquisterai la soluzione anziché costruirla. Ma ancora una volta, se aspetti fino a tardi nel progetto, fallirai.
Quello che sto dicendo, quindi, è che se identifichi i problemi abbastanza presto, puoi prendere provvedimenti per spendere più soldi in modo efficace per realizzare il progetto. E questa è la chiave: il tempismo è tutto. Incrociare le dita e sperare che "andrà bene la notte" finché non diventa chiaro che non lo farà, è una ricetta per il disastro. Una corretta gestione del progetto, monitoraggio, monitoraggio, analisi dei rischi, pianificazione e conversazioni con lo sponsor del progetto pagheranno sempre i dividendi e ti consentiranno di apportare modifiche abbastanza presto per essere efficaci, identificando i problemi il prima possibile, quindi spendendo i soldi necessari (o modificando altri aspetti del tuo approccio) per affrontare le questioni emergenti.
Sì, sarebbe fantastico avere una risposta universale a "come raccogliere fondi" :) Ma se devi scegliere penso che i beat di alta qualità siano in tempo per la maggior parte del tempo.
Certo, spesso siamo in ritardo e qualcuno dall'alto inizia a fare pressioni e noi cediamo e acceleriamo. Ma se finiamo con un cattivo prodotto verremo sempre (!) Ricordati come cattivi programmatori. Ho sentito persone lamentarsi della qualità dei prodotti finiti anni fa: gli utenti odiano ancora quegli sviluppatori perché continuano a utilizzare strumenti scomodi (in realtà gli sviluppatori non erano cattivi).
Allo stesso tempo, se non finiamo alcune caratteristiche cruciali , saremo nella cuccia per un po ', ma poi è possibile che il progetto venga finanziato ulteriormente a causa delle esigenze aziendali .
Ma se ti sei unito a un progetto che presenta molti problemi, è probabile che tu possa risolverne alcuni e accelerarlo.
Sono un sostenitore della Brooks Law ma non sono d'accordo con l'idea che sia vero al 100% il 100% delle volte con il 100% dei progetti. Attività diverse hanno diversi gradi di elasticità delle risorse in cui l'aggiunta di lavoratori avrà risultati variabili sia in termini di pianificazione che di qualità, a seconda dell'attività, a seconda dell'ambiente, a seconda dei materiali di lavoro disponibili, a seconda di una serie di variabili note e sconosciute che influiscono sui risultati.
Quindi penso che un budget infinito, se una cosa del genere fosse una realtà, potrebbe e avrebbe un impatto favorevole su un progetto problematico che deve affrontare problemi di pianificazione o qualità su alcuni progetti, in alcuni ambienti, per determinati tipi di problemi di causa principale. Credo che sia qualcosa che un PM e un team dovrebbero valutare caso per caso e sospetto che, con altre variabili casuali che influenzano i nostri risultati, a volte vinceresti, altre volte perderesti.
Mi sembra che la mia risposta sia vaga e ambigua; tuttavia, penso anche che i progetti complessi che trattano esseri umani complessi in ambienti complessi siano ugualmente vaghi e ambigui. Richiede analisi, innovazione, esperimenti e assunzione di rischi.