This post contains a list of questions I ask about any new client project. If you just want the list, skip to the end. If you want to know why I ask them, read on.
There are contractors who get their positive reputations by adhering strictly to “the customer is always right.” They do what they they are asked, quickly and competently, and if what they’re asked to do doesn’t actually solve the problem, well, that’s not their fault, is it?
These contractors will always find themselves with work; they’re easy to work with, and easy to recommend; they’re judged by whether they did the job, not by whether the project was successful.
I am constitutionally ill-suited to being that kind of contractor, so the value I offer is different: I am an expert at making software.
For me, the customer is right about their business and its domain, but I am usually right about what will bring the software part of a project to a successful conclusion. Because I will push back if I think my client is attacking a software problem in the wrong way, I get judged by stricter criteria: I get recommended when I help projects succeed, and I don’t get recommended if the project I’m on fails.
How do I make sure projects succeed? Well, obviously, some of it is skill and expertise: writing effective software that solves complicated problems, guiding the software development process, mentoring other developers so they can contribute more effectively, being wary of scope creep and slipping deadlines, and so on.
But some projects are doomed from the start, and if I don’t think I can save them, then the best thing I can do, both for the client and for myself, is to turn them down.
These, then, are the questions I ask before taking on a project. I ask them in order to decide if the project can succeed, if I can help it succeed, and if I will be able to provide enough value that the client will walk away happy. (Because, of course, there are also those projects that are already doing very well with the team they have; if I’m just going to be an expensive and unnecessary addition, I should still walk away.)
There are no wrong answers; and like everything about a project, the answers to these questions can change over time. A client might even be bringing me on-board specifically to help answer one or more of them. That’s fine!
But if the client doesn’t have real answers, and they’re not interested looking for them, then most of the time, I’ll walk away from the contract. The project won’t be successful enough for me to come out ahead. There are other reasons I might walk away, but that is among the most common. And, to be fair, plenty of clients walk away when I start asking presumptuous questions like these; it’s a good filter for both of us.
I wish I could say that clients I walk away from contact me again, later, with more suitable projects, but if I’m honest, that’s not been the most common outcome. I still ask, though; and I still walk away.
So here are the questions. I may have to ask several times, with different phrasings; and I will improvise follow-ups and deeper dives, but this short list covers a lot:
Success Criteria
- What’s success look like? What’s failure look like?
- What are some measurable metrics of success? Some intangibles?
Project mechanics
- What’s the budget? Do you want the best thing you can get for that price, or the cheapest thing that will do the job?
- What deadlines or time constraints are there?
- Who can make decisions? And where does the buck stop if there’s disagreement?
Usefulness and ethics
- Who will use the software?
- How will they find out about it?
- What alternatives do they have? (Competing products, but also, maybe, “a well-organized filing cabinet” or “a box of sticky notes”)
- What do users want? What do they need? What do you want from them? What do you need?
- What are the risks users face?
Reliability
- What does it replace?
- How long do you want the result to last?
- How often will it change?
- Who will maintain it?