What was your worst client request/specification?

Question

What was the vaguest, most contradictory, physically impossible, or sheer gibberish specification you have ever received from a client?

And more interestingly, how did you handle it?

Answer 1

An old boss of mine used to comment on a UI our team produced with something as "That's not very intuitive. Make it more intuitive." Of course he would not explain what "intuitive" really meant for him. We would change stuff, trying to make it easier to use (from our perspective) until either he stopped complaining or the deadline came close. Usually the former happened because of the latter :-)

Answer 2

There are a heap of these listed on Clientcopia. Quite a good read.

Answer 3

Many years ago, I was given a simple assignment for an table-driven input screen system, with a few fields. When that was done, my boss added a new features, field validation. When that was done, he wanted drop-down pick lists. After there pop-up sub forms. This went on for about a year, with several of the changes requiring major revisions to the underlying data structure. When it was finally done, my boss admitted that he knew the complete spec from the start "but I didn't want to scare you."

Update:(I probably should point out that this was done in the late 80's in C for MSDOS. It probably would have been a whole bunch easier in C++ for Windows)

Answer 4

On a web based system when a user clicks each field to lock just that field from others altering it. Can you imagine an ajax postback for every single field to do this?!

Answer 5

"The <feature> is not optimal to use but could be significantly improved. Please improve it."

I told the costumer that this isn't a requirement i can work with, and asked for more details. After several months, i still had no answer but also no more complaints, so i closed this issue.

Answer 6

Client: Implement a button on the customer view that opens the sales representative view for the customer.

me: In some cases there is more than one sales representative for a customer.

Client: That does not matter, just show me the sales representative, even if it's different from the other.

me: erm... ok

---

Implementation hint:

SELECT TOP 1 * FROM SALES WHERE ...

Answer 7

Once we had a bug report:

Bug: "The character's face looks blurred in the Cutscene. Please make the textures more detailed."

Answer: "Don't play in low detail settings."

Final Response: "Oh. Sorry."

Answer 8

We had been working for a government agency for a while, developing a rather big system and they wanted a new module, so they prepared a public contest for the development of the new module. The technical specs were one page long, where half of the page was description of the existing system, the other half was about the platform and a single requirements line:

"The module will have to do what is expected of it"

Of course we didn't have much competition in that contest and we certainly did have problems to agree when the module was finished. Gladly we already had developed trust and good communication so the agreements were reached.

Answer 9

Being asked to write ad/spy/mal-ware.

I used to do a lot of IE toolbar work (not because I liked it but because it paid bills) and most of it was innocent enough... But every once in a while you'd be half-way through a project and the client would ask "so how about we go ahead and add a feature to see what sites they've been on?" or "how about we check what's on the page to see if it's related to our product?".

The way the clients asked was always in a way that made it impossible to start screaming "I NEED AN ADULT!!" but that's pretty much what I wanted to do. Instead I'd have to spend days convincing them that breaking several privacy laws and moral boundaries just wasn't worth it. They were convinced that hiding a line in the installer EULA (if they hadn't just asked for a silent non-interactive installer, ffs!) would be legal protection enough.

Needless to say I don't do toolbar work anymore. There's still work to be had but I just can't deal with that sort of middle-management how-do-we-cream-our-customer way of thinking.

Answer 10

Once I was working on a project being specced not by the customer, but by a greek film director they had great confidence in.

When I was trying to flush out the desired behaviour in case of exceptional user behaviour (like obscuring their face e.g. by taking off their jumper), the reply came "IF ANDREA [the example user's name] OBSCURES HIS FACE THEN THIS IS A MENTAL PROBLEM IT IS AN ISSUE FOR A PSYCHOLOGIST NOT FOR [THE SYSTEM]."

And yes, all of his emails to me were in caps. In the end we decided to make it up when the time came.

Answer 11

One of my current projects is a web based service for my client that they actually sell as a service to their clients. Well after months of trying to get them doing planning and showing them how to get everyone's requirements and everything it came time to give a rough estimate and get a final requirements list.

Well what I got astonished me. It was an excel spreadsheet with a few points o the major parts, no details at all.

i would consider myself almost expert in the problem domain (their field of business) so I tried to get them to help me out and plan a little further, but no go. They just didn’t seem to want to do anything. So i decided to write up my own detailed requirements, since I knew pretty much what they wanted. I sent the first draft of it to them so they can see where I am going an d to build upon it. Well, after several months and a few vacations they didn’t do ANYTHING! (I heard stuff like, Oh sorry I was on vacation, and I replied, well that was 2 months ago).

So I decided that since I pretty much knew what they want I would go ahead anyways. OMG. That was a mistake. Well apparently their requirements were FAR beyond what they gave me and also expressed to me in the months leading up to staring, and the project has dragged on now for quite some time. The so called "domain expert" is the expert of... How to take long lunches... Some people are just impossible. If I hadnt already started when i figured all this out, i would have dropped it.

Suffice to say the project is starting beta and is nearly complete, but to get here was pure hell.

Moral is, Even if you are right, and the client is wrong, they are right. Don’t start without full requirements unless its an agile process, even if you think you know the requirements.

Why then you ask would I even have continued, well, it was a little hard, my wife works there and I also really want to see the project succeed, its one of those first in the market apps, where if we do it right, we could dominate. I normally wouldn’t touch this with a ten foot pole otherwise. :(

Another moral, don’t do work for anyone who employs family. It makes hard decisions much harder.

Answer 12

For an intranet web application where many users are not very familiar with computers:

"Please guarantee that our users will use the application."

Answer 13

Our industry would solve a lot of its problems if it moved from an attitude of 'the client is stupid, when will they get a clue?' to 'the client isn't trained in writing requirements, how can we best understand what they need and help them get it?'

I think some of the answerers on this page do understand that, but clientcopia is quite immature in this respect.

However, it does look like good training for developers - give them 10 problems from clientcopia and ask 'how would you have explained this/elicited the real requirement/set expectations for the customer in this situation?'

Answer 14

An Excel file to translate in web app with errors in it.

Answer 15

A long time ago, in a project far, far away...

There was an item in a contract for a simulator that said something like - "there should be a simple way to define a moving target" (but in swedish)

The contact was written by the supplier and it was agreed by the client in a traditional procurement fashion.

This was in Sweden and the word enkel was used. It is ambiguous and it can mean simple or easy.

The supplier meant "simple implemented" as this part in the project was a minor detail in the whole simulator as it also was a prototype

...then at the delivery time the client thought it meant "easy to use" (thing is that it wasn't the same persons receiving the simulator as it was purchasing). Someone thought they would get a full path editor in 3D with all possible features.

There was a time of confusion...

But after examining the price of the contract the customer agreed to the meaning to be "simple implemented"...but we made a second version with much better UI but not close what someone thought they would receive

Learnt lesson...be very specific and avoid ambiguous words

Answer 16

Mike

Good news. We got a new client. They want us to build a POS for reatail food industry. They say the user is not required to be able to read or count.

All for Now

--Bill

Answer 17

The worst one wasn't created by a client, but by a team of "business consultants" (several teams actually, from a pretty well-known consulting company too). The end result was about 5-7 Word documents over 500 pages on average (duplicating every piece of information in at least a dozen places), one Excel, and a powerpoint presentation for several hundred slides. Naturally, every document contradicted at least several other documents and, as it turned out, only one of the documents represented customer's needs more or less accurately.

We spent four months on a proper requirements specification, which took one 30 pages long Word document and a few Excel spreadsheets. Implementation took about 3-4 months afterwards.

Answer 18

Years ago I worked on an internal Decision Support System that required frontline staff to fill out things like how long they spent on various tasks. This was superfluous to their regular work, so almost no one did it.

I got a request from administration to "make staff fill out the DSS fields".

We made the fields mandatory, with the result that everyone typed "1" for everything.

We proposed hiring people to monitor floor staff and track tasks, but for reasons too long to explain this was not workable.

The solution we came up with was to run a contest for the best DSS stats.

Looking back on this project, I do not believe the stats we accumulated were any more accurate than simply using "1" for everything.

Answer 19

My favorite:

"I don't want visitors to our web site to be able to make copies of any of our pictures."

Answer 20

"The application shall be able to determine if the computer's hard drive has been tampered with."

We initially told the client that this was basically impossible without special hardware. The client rejected that explanation. We proposed several solutions, all of which were rejected by the client's "security expert" as not good enough. (Of course, the "security expert" couldn't propose any solutions of his own.) Eventually, the requirement was dropped, but we spent a lot of time on this before that happened.

Answer 21

I worked on a team that developed a new system to replace an old system. The old system needed a staff of about six people to use it: disk packs had to be exchanged, reports had to be printed and analyzed, and a couple of people had to monitor the system and perform maintenance tasks (basically, invoking the Reset function on anything that didn't seem to work).

The new system automated most of those tasks, and thus only required one person to monitor it and be there in case something went wrong.

Unfortunately, this didn't go over well with the workers' union. They didn't want jobs eliminated, and they did everything possible to get the system rejected.

So, as a compromise, management asked us to add the following "features" to the system:

• a "Manual Reset" function for each system component, to be invoked by an operator if the system's automatic maintenance functions didn't work (the Manual Reset didn't do anything that the system wouldn't do itself)

• printed reports which could be reviewed by maintenance personnel (which were useless for any real analysis)

• "review" screens for every automatic operation, so that personnel could verify that the system was doing what it was designed to do

So, in the end, the new system required the same amount of manual labor as the old.

Answer 22

Client: We need a time registration system to replace our existing system.
Us:     Why must the existing system be replaced?
Client: It's just an Excel sheet on a Windows share.
Us:     Ok. Good. Anything else?
Client: It must be a web application handling multiple concurrent users.
Us:     Noted. Anything else?
Client: It needs to look like the Excel sheet. Snappy UI; I'm thinking AJAX.
Us:     Noted. Anything else?
Client: Yes, it must be backwards compatible with the existing system.
Us:     Eh? How do you imagine that?
Client: It must use the Excel sheet as a data backend.
Us:     ......

Needless to say, the "snappy UI" was anything but. Luckily, we ran out of time before we could hack the hack, and the whole thing ended up on the scrap yard.

Edit: which reminds me; if you think Access is a terrible choice of a databse, you haven't tried Excel ;)

Answer 23

"The system shall interface to SAP as required."

This was in the agreed requirements document when I started. sigh