Finanziare progetti agili

Se sei stato in grado di fornire un preventivo su un progetto con una data finale esatta su tutte le funzionalità, perché hai adottato un approccio agile? Tu e tutti gli altri ci battiamo con questo e un approccio agile è in primo piano con questo fatto. Usalo come propaganda contro la concorrenza. Southwest Airline non ti promette un posto come tutti quelli che lo fanno e poi lo dà a qualcun altro.

Ovviamente il cliente desidera una data di fine esatta. Vogliono software economico e privo di bug consegnato in anticipo, indipendentemente da eventuali modifiche alla richiesta originale. Dillo al team di vendita per sapere come vendere un progetto utilizzando principi agili. Maggiore è il numero di interazioni che passi più vicino a quando il progetto sarà finito. Il cliente impara anche a valutare gli effetti delle richieste di modifica.

I progetti agili non funzionano sulla falsariga di "sarà pronto quando è pronto". Questa è una linea classica dell'ingegneria a cascata.

I progetti agili sono completi quando il cliente decide che non vuole spendere più denaro su funzionalità aggiuntive. Questo potrebbe essere convertito in un punto chiave di vendita da parte del personale di vendita. Invece di impegnarsi in un set fisso di funzionalità (la cui necessità può essere o non essere conosciuta in anticipo) per un importo fisso di denaro, il cliente può iniziare con un importo iniziale per un set di funzionalità iniziale e quindi eseguirlo per fasi. Questo garantirà un paio di cose:

• Finché l'elenco delle funzioni ha la priorità corretta, il cliente ottiene sempre le prossime funzionalità più importanti, massimizzando così il suo beneficio dalla sua spesa (ottiene "il più grande successo per i suoi dollari").
• Se il cliente esaurisce i soldi, ha massimizzato il suo investimento E sei stato pagato per ciò che hai consegnato. Nessuno si fa male, tutti approfittano.
• Il cliente può cambiare idea su priorità e caratteristiche ad ogni svolta della ruota (ogni fine di un'interazione). Un netto vantaggio rispetto ai normali contratti a prezzo fisso.

Probabilmente c'è di più, ma quanto sopra dovrebbe essere sufficiente per far andare i tuoi venditori nella giusta direzione.

Beh, non lo vedo come un caso di "Sarà pronto quando sarà pronto". La metodologia agile promuove l'offerta di deliverable su base regolare, come ogni due settimane. Ecco perché il cliente è una parte importante e molto attiva del progetto nel corso della sua vita in quanto fornisce una guida in termini di come le caratteristiche del tuo prodotto prenderanno forma. Se mai, un cliente inizierà a vedere i risultati prima, piuttosto che verso la fine di un progetto, come nell'approccio a cascata.

Finché ripeti il fatto che il cliente sarà parte attiva del progetto e vedrà che il progetto inizierà a prendere forma presto, ciò potrebbe assicurare che non si tratta di aspettare fino a quando non sarà completato .

Anche se il posto in cui lavoro fa un'orribile bastardizzazione di Agile, penso che i clienti preferiscano preferibilmente lo sviluppo di software nelle iterazioni rispetto alle versioni complete.

Le iterazioni si prestano a richieste individuali da parte dei clienti, nel senso che richiedono qualcosa e ottengono ciò quando la funzione viene implementata, non una volta che è stata eseguita e tutte le altre cose che sono state raggruppate per una release vengono anche eseguite.

Non ho mai visto un cliente dire "Vogliamo questa funzione, e vogliamo aspettare 8 mesi perché venga consegnata con una serie di altre funzionalità che non ci interessano".

Che ne dici di stabilire un ciclo di pagamento in sintonia con le iterazioni? L'idea di agile è che puoi solo pianificare e stimare in breve tempo, e la spinta e l'impegno sono ancora forti per questi brevi cicli. Quindi, perché non destinare i finanziamenti allo stesso modo - i clienti contribuiscono al lavoro con $$ e allo stesso tempo contribuiscono con la guida. Dopotutto, se non ottengono quello che vogliono, non dovrebbero pagarlo.

E poi capire cosa succede al termine di un progetto - ad esempio, il client possiede il codice o solo l'eseguibile? Ma ciò sarebbe in linea con i precedenti progetti a cascata.

L'idea di Agile è che tu esegua una rapida iterazione e stabilisci esattamente ciò che stai per consegnare alla fine di ogni sprint, quindi quando le 2/3/4 settimane dello sprint sono attive, hai caratteristiche tangibili nella tua applicazione / progetto che puoi presentare al tuo cliente e ricevere feedback.

ETA: potresti raggruppare gli "sprint" in "punti cardine", con deliverable stabiliti e ricevere pagamenti per milestone.

Io stesso non sono convinto che tu debba vendere un progetto fisso e gestire Agile dalla tua parte, ma piuttosto vendere iterazioni al tuo cliente.

Le iterazioni sono chiare per capire e non si mescolano i due concetti.

I seguenti due documenti ti forniranno alcune informazioni su Agile Management & interazioni del processo di vendita:

link & link