What are the techniques to elicit requirements from customers who don't understand their needs?

Question

Question:

How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?

Are there any techniques to help the client and us to get a clearer sense of what she expects?

Background on what we usually deal with:

We often develop (customize) CMS for clients. First and before any information structure is the "look and feel" of the website, the whole "identity", we could even say branding.

Beyond the fact that we are wire-framing the home page with tools like Balsamiq, and ask a lot of questions like:

1. If your website would be a person, how would he/she look like, behave, attitude have...?
2. What colors would you associate with your company / product / services?
3. How is your competition, how does they website look like, what do you feel about them?
4. What is your company mission statement, vision...?
5. How your business model looks like, Who is your target group, What the seek etc?

All of this later on in our costumers case most of the time is out of "their true vision of product / company / service design".

What is more one of our customers when we started to ask questions answered: "I need artist that will with himself find proper colours and prepare design. If he is truly artist when he will understand what mission we provide, the design will manifest from inside of him..."

So we also arranged meeting with both client and graphic that would remove any "chain factor", however client using world like: unique, prestigious, life saving, and giving also marketing materials provided totally other vision that graphic understood.

Graphic prepared nice modern design, that showed joy of life, product and company as happy place... As opposite to client vision (that he claimed after he saw project) as this institution has a machine that treats people and rescue life it should be: grey, sad, with attitude like at the funeral / church...

I know that we can adapt "after" he will provide us feedback, however this is tremendous waste of time, money and very often indicates frustration.

Answer 1

Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, workshops, and focus groups. Which means you need to understand the universe of stakeholders involved, their segments to which they belong, and the missions and values which are often times at odds with each other.

Requirements will conflict, and this part of the iteration process. You must de-conflict the offending requirements and rack and stack what remains. And then you will have your requirements baseline from which you can plan the rest of the work. And you will have--not may have--stakeholder segments who are simply not happy.

Regarding the work product part of the question, that's part of this process. Sometimes you must demonstrate functionality, customers have to play with the widget, before a decision can be made. It is part of the focus group and cost of doing business.

Answer 2

At the initial scoping phase of the project you need to understand what the client wants and what users want. Your project management skills will be tested in trying to balance both sets of requirements and deliver a product both are happy with.

To understand your client's requirements use the techniques that other answers have proposed including what you're already doing - asking questions. From experience I've found for larger projects it's good to start the process with a workshop (for smaller projects a face-to-face meeting usually suffices). This is really an ideas session but you will need to put some structure around it to ensure that you can engage your client and keep them focused on what you need - their requirements. For example, you might want to put some of the results from usability testing (see below) in front of them and ask them individually to write solutions on post-it notes and stick them on the wall. You can then review them as a group and agree on what the best solution is.

Follow-up the workshop with 1-1 interviews then produce a requirements document in whatever form appeals to your client - so a slide deck, a spreadsheet, etc. Ask for their feedback on the requirements document, reiterate and then get it signed off.

For gathering requirements from users do some usability testing!

There is no better way to understand what users' requirements are (and these are the people who matter most). The information you will get from engaging users is the most valuable information you will get about a website. It's also a great way to challenge what your client wants or believes they want. Informed usability testing cuts through personal opinions about how websites should work. You'll often find that what you thought would work for the user actually doesn't work at all, or gets ignored by the user. It can also validate new functionality that you've introduced. Ideally usability testing should be done throughout a project: during the scoping phase to gather requirements; after wireframing to test the concepts; after the visual design to test reaction to it.

There is lots of information on the subject in books and on the web (including the UX Stack Exchange site). Some typical usability testing techniques are:

• face to face testing: inviting participants to click-through the website while you observe, taken notes and ask questions (also try monitoring your behaviour during these sessions to inform how you can modify it for future sessions)
• lab testing: can be the same as above but if you can find the facilities, participants interact with the website while your client watches through a two-way mirror; you can also use eye-tracking tools to monitor where users eyes track across the screen
• online surveys

You can gather all of this data to improve deliverables on your current project and to plan for future projects.

The data gathered from the testing sessions can then inform your discussions with the client about what they want, what their strategy is, etc. Usability testing data provides a solid evidence base for making design and functionality decisions when planning your project.

Answer 3

I'm not sure we've answered the OP's question:

How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?

If I understand the problem correctly, the OP is working with the client to develop the initial requirements for the project (pre-initiation). The sticking point seems to be some soft non-functional requirements (NFR). (the look & feel/branding of the website). It is difficult to do user testing on NFR's (not impossible, but more difficult). If the OP's team doesn't convince the client that they can fulfill those requirements, then there will be no project. These are also soft non-functional requirements - there is no objective answer. The client doesn't know what the website should look like, (if they did, the whole interaction would go differently.)

I believe the OP has given the best answer so far; there are a list of questions to elicit subjective impressions of the brand and try to identify key themes that need to be reflected in the website design.

I would offer two further suggestions:

1. Check some books on advertising - part of the question falls outside the domain of project management. Very interesting stuff, but not PM. Some of the answers will bridge over into salesmanship where I'm not qualified to comment.
2. Prepare two or more alternatives based on the answers to the branding questions and ask the client to select the elements that work. Contextualize the experiment correctly - you're presenting some exploratory material to make sure you understand the NFR; actual fulfillment of the NFR will be part of the project execution after the project is chartered and planned.

Might be that some form of SWOT analysis could be adapted here to identify the concepts that are core parts (Strengths) and peripheral parts (opportunities) of the desired brand. The internal/external axis might represent the competitive advantage/discriminators from the competition. (I'm not familiar with it, but I think that the Gartner Magic Quadrant follows a similar model.) If the Project Team and the Client can use that as a structured process to identify the key features of the brand, I think they'll have identified a cluster of NFR's.

There is also an analogy to risk management. Risk management is an attempt to give the operations manager actionable information; the risk manager does that by decreasing the uncertainty on the unknowns. In this requirements exercise, the project team is trying to reduce the mutual uncertainty about the client's soft NFR. The key in both risk management and the OP's situation is that you don't have to solve the problem during the initial requirements stage, you just need to establish a framework and trust that the problem is bounded and that the boundaries will constrict over time to reach a final requirements set that matches the client's true needs.

The OP has asked what I believe to be a powerful question that has implication for scope management in many projects. I believe it is not at all uncommon for the stakeholder to either fail to express or be unable to express soft NFR's. Successful closure of the project means that the PM needs to uncover and quantify those requirements.

Answer 4

Would not delve in graphic design issues, since my aesthetic feeling may not be shared by others. As for eliciting customer's requirements, there are a few considerations:

How do you structure and dimension your product space?

a) Structure: what attributes of the product do you consider overarching and largely constraining your design? For instance, for aircraft it would be the required mission profile - what payload, how far, how high and how fast should it carry? It doesn't make sense to concentrate on ancillary product characteristics if inability to fix the top of the attributes' ladder leads to feature creep and multiple redesigns.

Once you've decided what attributes would generally come first, you have to make them as independent of each other as possible (we say orthogonal, perpendicular to each other).

b) To achieve attribute independence you would generally cull out attributes strongly correlated to each other and leave a manageable number of dimensions. Given clients' short attention span and your limited resources, would not recommend more than five dimensions altogether, preferably two or three (to leave clients some choice).

Next, what are the extremes at each dimension? Say, a regional jet or a jumbo for Trans-Pacific flights? (note to self: avoiding car analogies? check) Prepare sketches of design for each combination of extremes and sit with the client to see how he feels about the variants. (Don't try to second-guess him now - the money is his.) Let him know these are just rough approximations and will be refined as more preferences are revealed. Refine, fixing his decisions on what is and what isn't acceptable. Repeat the process...

There is another route (which works for less subjective products, though): finding someone with enough knowledge of both the client's industry and your subject domain and enlisting him to work as 'an interpreter'. However, the usual complication is that a 'middleman' whether he works full-time for you or not brings a whole set of own biases and preferences into play, and possibly a hidden agenda as well.

Answer 5

"How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?"

You can't in a lot of cases. But from what I've read/understood of your question, it all comes down to risk management.

You said:

What is more one of our customers when we started to ask questions answered: "I need artist that will with himself find proper colours and prepare design. If he is truly artist when he will understand what mission we provide, the design will manifest from inside of him..."

Translated that says - I want an artist that can read my mind.

With a client like that you have two choices - keep trying to draw out requirements, and then document those and be very clear and specific, or build the process of demos and prototyping into the cost. Start with a crude idea and get feedback and build from there.

Answer 6

Maybe I've missed it in other answers, but I think one of the key pieces is to gain a better understanding of what the client is actually trying to achieve at a high level.

• Measureable goals

  • Increase overall market size?
  • Take users away from competitors?
  • Prevent current users from leaving?
  • Be seen as the best solution in the space?
  • whatever else they are trying to achieve, as long as it is measureable in some fashion

• Constraints

  • What can't they do?
  • Are there regulations that they need to follow?

• User personas

  • Who are they targeting? (this needs to provide insight, not just a few words)
  • What is the context does this person use this product in?

Building this with the client can help not only point you in the right direction, but will often help get the client to think (and express) more about what the final product should look like.