Client requirements: The shape of the elephant, part 2

By Gordon Rugg

Identifying and clarifying client requirements isn’t always easy. However, that isn’t the same as “impossible” or “not worth trying”.  The better your understanding of the requirements, the better the outcome is likely to be. This article is about three bad responses to client requirements, and about better ways of tackling the problem.

As a running theme through this series, we’re imagining that you’re dealing with a client who has asked you to produce an image of an elephant. Here’s one bad solution from the past.

Bad solution 1: Sod it, this will do, they don’t know any better.

Client’s response: You’re wrong about that, and you’re fired.

So how does this situation arise, and what can you do about it?

A key concept in this example is the distinction between satisficing and optimising. These are concepts from the work of economist and decision theorist Herb Simon. A satisficing solution is a good-enough solution; an optimising solution is a best-possible solution.

It often makes sense to go for a satisficing solution, because that usually saves you time as well as money. The trouble with an optimising solution is that usually you can’t know when to stop looking for a better solution, because you have no way of knowing what’s still out there that you haven’t found yet.

If you’re going to use a satisficing solution, then you need to be clear about that with the client, and to get the client’s agreement about what they and you will consider to be a good enough solution. That takes you into territory like metrics and measures, which are well-established concepts in some disciplines, and not so well known in others.

We use laddering a lot for identifying and unpacking the relevant measures. There’s a tutorial article about this on the Hyde & Rugg web site. It’s a cheap, simple, clean and powerful method that only requires pen and paper.

Click to access laddering.pdf

We also use laddering to unpack why the client wants a particular requirement. This is an important issue, that we’ll return to at the end of this series.

Bad solution 2:  Red is the new black

Client’s response: Then go work for Prada. You’re fired.

As with the previous example, sometimes this is actually the correct way to tackle the problem. One key issue is whether you’re dealing with the design of a novel product or a new version of a well-established product.

This is one of those cases where English doesn’t have exactly the word that’s needed. A novel product is one that “breaks the mould”. Another way of phrasing this is to say that it is based on a new schema. A schema is a mental template for something; for instance, the first Graphical User Interface was a new schema, very different from the previous interfaces based on the old schema of command lines.

https://hydeandrugg.wordpress.com/2013/08/30/schema-theory-scripts-and-mental-templates-an-introduction/

If you’re designing a truly novel product, then you’ll usually want to be very different from current fashions and conventions, so you don’t get pigeonholed as being still in the same old schema that you’re trying to replace. Also, the current fashions and conventions might actively get in the way of your new design. We had this issue when designing the Search Visualizer software, where we deliberately made the interface and menu structure very different from those in previous search engines based on the old schema.

http://www.searchvisualizer.com/

If, on the other hand, you’re just designing a product which is a new variation on a well-established theme, then you’ll need to be sensitive to current trends and best practice, so you don’t look outdated.

This is a common cause of problems in design and development. The key skill sets for designing and developing a truly novel product are very different from those required for designing and developing a new variation within a well-established schema. It’s not a case of one approach being inherently better than the other; it’s just that they’re very different. It’s a good idea to check for which of these you’re dealing with as early as possible in the process.

Bad solution 3: Here’s one I found on the Internet.  

Client’s response: You can find a new client there while you’re about it.

Again, this is sometimes an appropriate solution. This is particularly relevant in the case of software development, where there’s a lot of good open-source software available that can significantly reduce development costs both in time and in cash.

Often, though, it’s a problem. In the case of open-source software, that software may not do exactly what you want to do, in which case you need to spend time and effort modifying it. Modifying someone else’s code isn’t a lot of fun, and doesn’t always end well. Most programmers at some point in their working lives will have an experience with their own code where they leave a particular chunk of code alone, because it works in its current form, and it breaks if they alter it, for reasons that they’ve never been able to understand.

Another issue involves the signals that you’re sending out to the client. If you’re downloading someone else’s solution from the Internet, what does that say about your own skills, or rather, about your implied lack of skills?

Also, it raises questions about whether you’re aware of potential legal issues involving copyright and fair use. For instance, there are honeypot websites, full of gorgeous innocuous-looking images of things like freshly-baked cakes or beautiful views, that can be used in a wide range of settings. The honeypot site’s owners then use image-search software to trawl the web, finding websites that have downloaded and used the honeypot images without permission, and send a legal letter demanding a huge fee for using the image. The unauthorised users don’t have a legal leg to stand on.

If you decide to go down the route of using material from the Internet, it’s a good idea to talk the client through your decision rationale, to set their mind at rest about this aspect of the project.

https://hydeandrugg.wordpress.com/2013/08/27/decision-rationale-the-why-and-the-wherefore/

Summary

In all three cases above, the problems involve mis-application of principles that can actually be sensible or even best practice in a different context. The solutions in all three cases are cheap and simple, once you know what they are. There are articles on this blog site and on the Hyde & Rugg website that cover these issues. We hope you find them useful.

Links and notes

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

The elephant images above are from wikimedia and Wikipedia, and are used here under the creative commons licence.

I’ve followed our usual convention of showing in bold italic useful terms where it’s easy to find further information, and of only including links where it’s difficult to find further information, or where a specific site is involved, to reduce link clutter.

Advertisement