Migliore approccio per l'offerta di un progetto

Offrire un progetto (che presumo sia quello di cui si sta parlando) è sempre difficile. Se provi a eseguire i passaggi seguenti, sarai in una buona posizione:

• Assicurati di avere un set completo di requisiti. Ovviamente avrai bisogno di input da parte del cliente qui e avrai anche bisogno che sottoscrivano questi requisiti.
• Una volta soddisfatti i requisiti, prova scomporli nel più piccolo pezzi possibili. Questo lo farà più facile stimare quanto tempo ci vorrà prendere per implementare ogni pezzo. Prendi la somma di questi pezzi come base per quanto tempo ci vorrà per sviluppare (datti un po 'di padding)
• Quando il cliente viene da te con novità requisiti (che cercheranno) indirizzarli nel prossimo sviluppo ciclo. Mi piace usare un phased approccio allo sviluppo, questo consente per far firmare i clienti la funzionalità originale che hai accettato prima di guardare cose aggiuntive.

Se ti preoccupi di ridurre al minimo i tempi di offerta del progetto, rischi di fallire il progetto o di impiegare più tempo del previsto. È possibile che tu possa perdere l'offerta, ma probabilmente è una buona cosa. Preferirei non ottenere un progetto piuttosto che ottenere un progetto da un cliente che non ti dirà cosa vogliono.

Stimare lo sforzo richiesto durante il processo di offerta è sempre difficile, soprattutto quando non si sa esattamente come risolvere il problema perché i requisiti sono complicati o ambigui.

Se i requisiti sono ambigui, proverei sicuramente a identificare le aree che non sono chiare e inviare una lista di domande al cliente per chiedere chiarimenti.

Se il tuo problema è che il progetto è complicato e non sei sicuro al 100% quale sia il modo migliore per risolvere il problema, sarei propenso a presentare un'offerta per il progetto sulla base del fatto che trascorrerai le prime x settimane a valutare i requisiti del progetto e la prototipazione delle possibili soluzioni. Non è irragionevole chiedere al cliente di pagare per questa volta, in particolare se il lavoro è complicato. Vorrei stimare quanto tempo è necessario per identificare tutte le incognite e risolvere eventuali lacune, e dare al cliente una stima solida per quella parte del processo.

Inoltre, stimerei quanto a lungo il progetto totale assumerebbe ipotesi pessimistiche, e quindi aggiungere il 30% - 100% a seconda di cosa pensi sia il budget del cliente. Fornirei loro questa stima approssimativa dello sforzo totale previsto, ma chiarire che lo sforzo è condizionato a raggiungere un ambito, un'architettura e un piano di implementazione chiari e concordati.

Penso che la maggior parte dei clienti apprezzeranno questo tipo di approccio, in particolare se il progetto è complesso e se disponi di competenze pertinenti.

Sembra che tu stia cercando un progetto di offerta fissa e tu e i tuoi colleghi non ne avete mai fatto uno prima. Non raccomanderei nemmeno di fare offerte per il progetto nella tua situazione. Se la tua azienda non ha la forza finanziaria per assorbire un totale mancato sulle stime dei costi (pensa almeno al 100% di superamento) e continua a operare, poi scappa. La precisione richiesta per scrivere il contratto per evitare lunghi periodi di avvocati che urlavano l'un l'altro a $ 300 / ora, il dettaglio richiesto nei requisiti (per limitare lo scopo) per assicurarsi che il cliente non sottotri i posti obiettivo più lontano vicino al terminare, i dettagli su ciò che consita la consegna di successo, problemi di garanzia (più breve è il migliore) è difficile. Le aziende grandi e con esperienza falliscono in questo momento. L'unica ragione per cui vedo di fare un progetto di offerta fissa è la carota di un contratto di assistenza pluriennale da seguire al termine del progetto. Senza quel flusso di entrate extra, il rischio / rendimento non è allineato per i fornitori. Ci sono ragioni per cui le statistiche dicono che il 60% dei progetti software falliscono (o qualunque sia il numero questa settimana) e l'offerta fissa non la risolve e il solo passaggio del rischio al fornitore / sviluppatore non risolve il problema. Stai ancora per cambiare idea, scopri che i requisiti non soddisfano le esigenze del mondo reale, e ora ci sarà una lotta per chi pagherà il costo del cambiamento e se non sei disposto a spendere l'intero contrattare i contratti per assicurarsi che il tuo cliente sopporti il costo del cambiamento, perderà denaro su questo. Inoltre, dall'esperienza, le offerte fisse danneggiano il tuo cliente e finiscono con il software che soddisfa i requisiti del contratto e non le loro esigenze di business. Lasciare gli impegni IT di offerta fissa alle implementazioni dei sistemi di posta elettronica e tali sono molto più prevedibili rispetto alla creazione di software.

Sei abbastanza concentrato a capire come ottenere un numero di prezzo fisso, ma ti incoraggio a pensare ad altri tipi di contratto, come tempo e materiali o costi più. Il modo per renderli appetibili al cliente è proporre specifici traguardi e risultati lungo il percorso, in modo che possano vedere i progressi e stanno facendo pagamenti incrementali.