ProofDevs
Specialists for this

Proposals

Warning signs in a proposal

Free analysisNo commitment2 min

What is actually going on

Projects that fail rarely fail suddenly. The conditions are usually present in the proposal: an estimate produced without inspection, a scope with no boundary, or a supplier who will not say who does the work.

How the work runs

Step 01

Note every signal you see

Count them rather than weighing each. One is normal, three is a pattern.

Step 02

Ask about each one directly

How the supplier responds to a direct question is more informative than the original signal.

Step 03

Get an independent read if two or more persist

An hour of someone else's time is inexpensive against a project that stalls at sixty percent.

In the estimate

These indicate that the number was produced by a process you cannot inspect.

  • A fixed price arrived within a day or two, without anyone examining your existing system.
  • One line reading 'development' with a total against it.
  • No assumption list anywhere in the document.
  • An exact figure with no range, on work that has never been done before.
  • A discount offered for signing quickly.

In the plan

These indicate a schedule written to be attractive rather than to be met.

  • A timeline with no dependency on anything you have to provide.
  • No phases, or phases with no visible deliverable at the end of each.
  • Testing absent from the plan entirely, or listed as a final week.
  • A rewrite of existing working software recommended in the first conversation.
  • The word 'agile' used to explain why the scope cannot be stated.

In the commercial terms

These are the ones that are hardest to fix after signing.

  • Ownership of the code not stated, or transferring on final payment.
  • A large payment up front with no deliverable attached to it.
  • No stated process for handling changes.
  • Hosting or accounts held in the supplier's name rather than yours.
  • No exit terms: nothing about what you receive if the relationship ends early.

In how they behave

The softest signals, and often the most reliable.

  • They will not name the person who would do the work.
  • Technical questions are answered with vocabulary rather than explanation.
  • No questions asked about your business before quoting.
  • References are offered but never quite materialise.
  • Pressure to decide before you have compared anything.

Common questions

How many of these is too many?

One is usually nothing. Two deserves direct questions. Three or more, in a project large enough to matter, is worth an independent review before you commit.

What if the supplier was recommended by someone I trust?

A recommendation tells you about a previous project, not yours. The signals above are about this proposal, and they apply regardless of who made the introduction.

Related

How to Evaluate a Software Development ProposalRead thisHow to Compare Software Development Proposals Side by SideRead thisIndependent Review of a Software Development QuoteRead thisSoftware Second OpinionRead this