Client requirements: Why clients change their minds, and what you can do about it

By Gordon Rugg

This article is one in a series about the problem of identifying and clarifying client requirements. This episode looks at why clients often appear to change their minds dramatically, and how you can handle that problem within your development process.

Readers who like the extended metaphor of the client requiring an image of an elephant might like to know that we’re continuing with it in this article. Readers for whom the novelty of that metaphor has worn thin might like to know that we won’t be using it much.

So, why do clients appear to change their minds radically? It’s often because of a very simple reason that is easy to handle.

Often a client will be clear, firm and decisive about one of their requirements, even if the other requirements are fuzzy and/or negotiable. It’s tempting to assume that the clear, firm requirement is the one you should treat as a fixed starting point. However, that isn’t necessarily the case. Sometimes, in fact, it’s the worst place to start, since those firm, clear requirements are often a real pain, like the client who insists on using an elephant as the product logo, or who wants the building to have a thatched roof which is going to be a nightmare to instal, or the client who wants the software to include a feature that will cause a lot of upgrade problems.

I often have to deal with a very similar issue when I’m helping students to choose the topic for their final year or MSc project. I have strong feelings about this, since a little support at this point can help students to achieve far more on their projects than they ever thought possible. I’ve known undergraduates who liaised with leading figures from forensics and Hollywood as part of their projects, for instance.

The usual script I use for the conversation is to ask the student what their dream outcome would be, and then to craft a project topic that’s a stepping stone toward it. One thing I learned long ago is that the conversation shouldn’t take that dream outcome as the final goal. Here’s why.

A common answer about the dream outcome is getting a well paid job. It might look as that is the end point, but you often get very interesting replies if you ask why they would like a well paid job. Here’s one common answer.

Slide1

A lot of students want a well paid job so that they will have enough money to travel. The “dream outcome” is actually just a sub-goal, on the way to the real dream outcome, which is to travel.

Once you know what the real dream outcome is, then you can start to think about other ways of getting there. Here’s a classic alternative route, in green.

Slide2

If you get the right sort of job in the travel industry, you can be paid to travel. When the student looks at this option, they often swiftly decide that this makes a lot more sense than doing a boring well paid job and then spending their own money for a limited amount of travel a few days per year. So, you end up with this situation.

Slide3

It looks as if the student’s requirements have changed dramatically. In fact, the top level goal has remained unchanged; it simply hadn’t been mentioned in the initial conversation. All that’s changed is the route to that goal.

It was a similar story when we developed the Search Visualizer software. The top level goal was helping people find relevant documents. Most other people were trying to do this using words, by showing text from each document. We realised that a much more efficient solution was to show where the user’s keywords occurred. This was a completely different route to the same top-level goal. It also had some useful bonus side-effects, like letting users identify documents in other languages that were worth getting translated, or helping users to find relevant sections in very long texts.

The approach we use to find out higher level goals is technically known as upward laddering. In practice, it looks to the client like a simple question about what they’d love to have as a dream outcome.

Often, you can also do downward laddering from that dream outcome, by asking the client whether they can suggest any other ways of getting to that outcome. This usually makes the client happy, and might produce some sensible ideas. If the client can’t come up with other suggestions, then you can use idea generation techniques such as Idea Writing or constraint relaxation to come up with some possible routes that would be more suitable than the client’s original one.

In the next article, we’ll look in more depth at ways of achieving goals, and at ways of establishing whether those goals have been met.

Notes

This series consists of Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, and Part 8.

As usual, I’ve used bold italic for technical terms where it’s easy to find further reading. I’ve listed some specialist links below.

Our previous article about Idea Writing is here:

https://hydeandrugg.wordpress.com/2013/09/21/idea-writing-generating-practical-ideas-quickly-and-efficiently/

There’s a tutorial article about laddering on the main Hyde & Rugg site here:

Click to access laddering.pdf

The Search Visualizer site is here:

http://www.searchvisualizer.com/

The Search Visualizer blog is here:

http://searchvisualizer.wordpress.com/

Advertisement

10 thoughts on “Client requirements: Why clients change their minds, and what you can do about it

  1. Pingback: One hundred Hyde & Rugg articles, and the Verifier framework | hyde and rugg

  2. Pingback: The “compass rose” model for requirements gathering | hyde and rugg

  3. Pingback: 150 posts and counting | hyde and rugg

  4. Pingback: Client requirements: The shape of the elephant, part 1 | hyde and rugg

  5. Pingback: Client requirements: The shape of the elephant, part 2 | hyde and rugg

  6. Pingback: Client requirements: The shape of the elephant, part 4 | hyde and rugg

  7. Pingback: Client requirements: The shape of the elephant, part 3 | hyde and rugg

  8. Pingback: Requirements that clients don’t talk about: The elephant in the room | hyde and rugg

  9. Pingback: Client requirements: Finding boundaries, constraints, and the shape of the elephant | hyde and rugg

  10. Pingback: Requirements, evaluation and measurement: How to tell if you’ve met a client’s goals | hyde and rugg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.