Software gets evaluated thoroughly and partners get evaluated on a proposal document. That is backwards. The product will behave much as advertised. The variable is who configures it and who answers the phone in month six.
Questions worth asking
- Who exactly will run this project, and are they on this call?
- Show me your awkward-case demo, using our document types.
- What is explicitly out of scope in this proposal?
- Who answers support in month six, and what is the response commitment?
- What happens to our source code and data if we part ways?
Ask to meet the consultant who will actually do the work. The gap between the sales team and the delivery team is the single best predictor of how a project will go.
Answers that should worry you
| You hear | What it often means |
|---|---|
| "The system does everything" | Nobody has scoped your processes yet |
| "We will sort that out during implementation" | It is not in the price you were quoted |
| "We are certified compliant on your behalf" | An overstatement no software partner can make |
| "Training is included" | One session, too early, for everyone at once |
| "Go-live in four weeks" | Configuration only, with migration unscoped |
Put these in writing
- Named project lead, with a change process if they move.
- Explicit out-of-scope list, not just an in-scope list.
- Data and source code ownership, and what handover includes.
- Support terms after go-live, with response times.
- Acceptance criteria per phase, agreed before build.
