The client vetting process is the most important step in business. Not only can a failed project leave your business in the red, it also wastes time, resources, and hurts future prospects. But it is a paradox that the most important step in business be conducted in an expedient manner. The time spent evaluating a client costs time, money and is not directly billable. But what are the best questions to pre-qualify a client?
The key to effective client evaluation is identifying the perfect buyer for the service. The perfect buyer is not only the one who will pay the most, but the one who will receive the most value, and has the greatest chance of providing a successful outcome.
The Introduction
The first meeting with a client is much like a first date. You’re both interested in getting to know the other person, what they can provide, and what their needs may be. Some initial icebreakers could be:
“What is your role in the company?”
“Which competitor keeps you up at night?”
“What do you see as the biggest challenge this year?”
“What are some pain-points your business is having with X?”
The Scope
A typical evaluation most always starts with, “what is the scope of this project?” This establishes what the client thinks they need, and also identifies the depth of business value you will be providing. The most successful projects will begin with some type of specification document. This can be either high-level business specifications, a list of functional requirements, or even full-blown design mock-ups. From this scope document, create a ballpark budget estimate for what you would need in order to do a professional job on this project. This leads into the second question, which is inevitably: “what is the budget?”
Show me the budget!
It’s absolutely fine if the client does not have a definite number in mind. One of your first tasks may be taking the scope, and formulating a ballpark budget. This is best done on your own time, and not something you should throw out on the spot. Creating a realistic budget, albeit a ballpark one, sets the tone for the remainder of the engagement. Ensure the budget can realistically pay for the project scope in a way that won’t cause unprofessional quality shortcuts. The only thing worse than an underfunded project, is a project which doesn’t ship. An underwhelming case study provides no credibility on which to further your business.
Other people’s code
If you will be working within an existing codebase, make sure to check it out! Codebase health, missing dependencies, undocumented “magic”, and exotic libraries can cause a seemingly simple project to bog down.
Ask about:
“What is the state of the current codebase?”
“How many developers have worked on the codebase prior?”
“Are there specifications (technical and design)?”
“Who is the original architect?”
“Does the codebase run on modern hardware?“
“Can I contact the last person to work on the code?“
It is not unusual to request a source code review before taking on a project. Signs of a healthy codebase include unit tests, documentation, and proper object oriented design. An unhealthy codebase is not necessarily a disqualifier. On the contrary, codebase improvements are an excellent opportunity to expand the scope of work. (Assuming the client agrees and has budget.) Frame the improvements in terms of business value.
No developer is an island
Every project has timeline impacting dependencies. It’s important to assess the state of these dependencies, as one missing screw can delay the project indefinitely.
Ask about:
“Who else is on the team and what are their responsibilities?”
“What are your expectations on my availability? (Will there be phone calls at 2am…)”
“What is the state of dependencies? (Are they complete or in-progress?)”
“Is there a test API environment?”
“Can the code run locally?”
“Is there anything proprietary or exotic?”
The Daily Rhythm
The day-to-day process sets the rhythm of work like a human metronome. Will the client be calling at all hours of the night, or disappear for weeks at a time? Establish a communication routine with the client from the onset to ensure everyone is on the same page. Consider the following things:
“How will the client deliver feedback?”
“What are appropriate hours for a telephone call?“
“When and how will status updates be given?”
“How many times a week shall we meet in person?”
“How many revisions can be expected before a feature is complete?”
Final Approval
An important question I have learned to ask after much experience (and mistakes) is “how do we determine when we are done?” This is commonly referred to as the ‘success criteria’ for your end of the project. This must be as clear as possible, and above all, realistic.
“Who will have final say on the work product?”
“Who will handle QA?“
“Who will handle production deployment?“
“What is the after-deployment plan?”
High fives all around
After the project is an explosive success, make sure people know about it! Ask about the marketing plan, and how the project will be advertised. How can we support the social media team? What content-marketing is scheduled the week of launch? (Is there any plan at all?) After-launch support is a professional way of providing ongoing value on a retainer basis. Apps need maintenance, crash handling, and support after launch. Delivery of the final work product can be the start of a great partnership!
So many questions and no answers
To wrap up, I’m sorry if you read this whole article looking for answers and instead only found questions :) The right answer is different for each situation and depends on your own judgement as a business person and a developer. We all make mistakes, and there is a fair bit of risk involved with each business venture. Maintain a good attitude and always be professional; everything will work out. If it doesn’t, there’s always beet farming.
