1. When is the ‘Why’ more important than the ‘What’?
This is the first question we should ask when approached by a client. Just because someone thinks they know what they want doesn’t mean they have a completely clear understanding of why they need it. In other words, the ‘why’ relates more to how it fits into the overall strategy of the business.
For example, a client may ask for a full restyle of their site, but further probing uncovers the fact that the database structure doesn’t support the addition of multiple clients, which will require a larger rewrite.
Asking, ‘why are we doing this?’ helps to narrow down what the client really needs. This saves resources and headaches so they don’t end up with something they’re unhappy with in the long run.
2. Who will be using the end result?
Not who is paying us to build a system.
Get to know the end user; they should be your contact for a lot of the questions you’re dealing with. Knowing the end user removes the confusion of talking to the client, who talks to the end user, then passes the information on to you. Remember playing telephone as a kid? And how the final message was never anything like the original? Exactly. A lot can be lost in communication when people aren’t as familiar with the system.
Also find out what they’re using now. Do they have a system? What are the pain points? What is the ‘killer feature’ that would make their day? A lot of times, it helps to get to know the people who are actually going to use what you’re making.
3. What don’t we need?
Maybe the client needs to input data, so we assume a full CRUD (Create, Read, Update, and Delete) interface. If, in reality, they don’t need to be able to modify, view, or delete this data from the application, we’re wasting effort. Depending on timing, it might be better to go back and add that later once the client changes their mind.
Figure out the scope of a feature, what’s included, what’s excluded, and document all of this information. Inevitably, at some point clients will change their minds on something. Just take it in stride, find out where it belongs on the priority list, and move on.
4. What will it really take?
Be realistic about time after the development cycle. Spell out the process for what happens after development is done. Allocate enough time for testing, deployment, etc. This doesn’t mean burning time from testing because you’re running over on features.
Remember, this has to keep your due date in mind. If the due date is a month away but you budgeted two months for testing, then that doesn’t add up.
5. Who’s in charge?
Who’s actually in charge might not be the same as who’s supposed to be in charge; seniority may not trump domain knowledge. In The Lord of the Rings, Gandalf seems like he’s in charge of the fellowship, but when it comes down to it, the group always follows Frodo because the whole mission depends on him (a little nerd spice for you guys). Try to figure this out and agree to it beforehand rather than face problems later on.
