“The collaboration was successful” is reassuring to read in a reference. It tells you little about how the supplier handled a delayed decision, a difficult acceptance review or a fault after launch.
If you can speak to a previous client, focus on challenges similar to yours. Someone who worked with the team day to day can usually give you more useful detail than someone who only signed the final acceptance document.
Establish the context first
Ask about the scope, delivery period, the contact's role and the client's own contribution. The project may have relied on an internal technical team or someone available every day. If you cannot provide those resources, the same working arrangement may not suit you.
Five questions worth asking
- Did the people introduced before the agreement actually work on the project?
- When did you learn about possible delays, and what happened next?
- How did you agree the cost and impact of new requirements?
- How were defects handled during acceptance and after launch?
- What would you prepare differently if you started again?
Ask for one example when an answer is broad. “Communication was good” becomes useful when you understand what good communication looked like in practice.
Separate events from opinions
Record what happened, how the team responded and the outcome. A delay alone does not establish who caused it. Equally, a positive recommendation cannot demonstrate skills that the earlier project did not require.
Avoid collecting confidential details or unnecessary personal information. You are assessing how the project was delivered.
After the call, return to your own priorities. If ongoing support is critical, a reference for a design-only engagement leaves that question unanswered. Find relevant evidence instead of treating every positive reference as interchangeable. The goal is a clearer view of the proposed collaboration, including what you still do not know.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database