Attitudes in IT - Mediocrity Wins?

podo asks: "I've spent the past two months of my life working almost full time on a PHP/MySQL based web site for a client. Today I received an e-mail from the client point me to a similar web site set up by a competitor. 'Doing exactly what we are doing.' The site in question is not doing what we are doing, they have no dynamic content, no web forms, just e-mail addresses. They scarcely have any content (I counted only four HTML pages) at all. The client is chastising me for taking a long time and because the other site is 'much more impressive visually' than ours. Has anyone else found themselves in a situation where their painstaking work is compared to work which is a showcase for mediocrity? How have you dealt with such clients who fail to see the difference between a shoddy rush job and real quality?"

Comments

Hmmmmm

[MrIcee]

It is difficult to respond to your question. You don't give us any ideas as to how big your site is in comparison to the 'competitive' site.

For example, you state they only have 4 pages of content - how many do you have, etc.

There are a number of things about your post that strikes me as a bit odd. For example... when we bid projects we give a firm one-time price and a firm one-time delivery date. These are always adhered to - come hell or high water. Of course, changes to the specification can cause changes to the price and timeline, and our clients are aware of that - but as long as no changes are added to the original requirements document we ALWAYS meet our deadlines. Your post tends to leave that kinda open ended (I've given two months of my life - well, didn't you SPEC THAT OUT?).

Secondly, a MAJOR part of our client relationship is TEACHING THE CLIENT what a good website is, etc. Since almost 100% of the sites we do are heavy cgi-bin coded sites (C) with database handling, image processing, etc... there are many factors in such sites that require us to teach the client why one approach is better than another approach. THIS SHOULD BE DONE UP FRONT - NOT AT THE END. You have committed to an approach, but it doesn't strike me that you have educated your client as to the pros and cons of your approach.

Step 1: Discuss the clients needs with the client and show them examples of a number of solutions and outline to the client why each solution is better/worse than the others.

Step 2: Have your client give you feedback on which approach they wish to take, and why. Keep in mind how the site might progress in the future.

Step 3: Deliver to your client a detailed specification that outlines the site, the engines, how they work, how navigation works, how the site graphics look and feel, firm FIXED price and timeframe to delivery. Include periodic goals to show the client (we actually allow the client to critique the design while it is in progress)

Step 4: Create said site, in said timeframe and for said price.

At this point, it doesn't matter what the competitor does or did - the CLIENT was offered all the solutions and all the pros and cons and was properly educated as to why each was good / bad. OBVIOUSLY the competitor also selected one of those solutions - if they didn't, you left one out of your explaination. But assuming that you did your work correctly - than the client will ALREADY know the competitors site sucks (or cost a boatload more) and they will know why.

Most likely the call you will get from your client is *hahahahaha, check out the crap that the competitor did - man are we glad we went with you*.

What does this have to do with IT?

[LordNimon]

Every industry has situations where the consultant does some good work, and then the client complains that it took too long or cost too much, and he points to some lesser-quality alternative as an example. I don't see how this problem is unique to the IT world.

And the resolution is the same in every case: either the consultant over-estimated what the client wanted (in which case, the consultant is in trouble), or the consultant has to explain to the client that his so-called alternative really isn't that great.

Nothing to see here ... move on.

A little help with the flogging...

[Snerdley]

I'm sorry to say that I agree with most of these posts: you didn't find out what your client cared about before you started coding.

However, to hopefully help you out of this mess, here is some light reading that you might find useful:

1) Read Don't Make Me Think (not on safari yet) by Steve Krug. It's the best web usability book out there and will take you all of two hours to go through. His usability testing alone would have found your problem earlier.

2) Read Eric Meyer on CSS(no safari) to find out how to make your site look better. If you can find/afford a designer, use them, but learn how to abstract your design from your code and your life will be much easier. (If you like it, there is More Eric Meyer on CSS (safari) as well.

3) If you're trying to do public sites, I've found Submit Now (safari)by Andrew Chak to be an excellent read. It's common sense, but its good to be reminded.

I hope this helps, and good luck salvaging the gig.

Yes, But Make Sure Client Knows What He Asked For

[reallocate]

>> LIVE BY THE REQUIREMENTS.

Absolutely. But it is your responsibility to make sure the client understands what will be delivered when you meet the requirements. Part of your job is translating requirements-speak into client-speak.

After being burned (as the client) I learned to schedule a session whose only purpose is to have the client outline for the designers what he thinks the requirements mean. Tends to clear up a lot of confusion before the real work begins.

Explain the differences

[KidLink]

Put together a list of differences between what you are putting together and what is on the website in question. Make the list detailed as possible, things that are obvious to you are clearly not so obvious to them. E-mail the list in a polite manner to inform the client of the differences, and that yes, if they want to drop any of these features it will simplify and speed up the development process. Then they can decide if the extra features justify the extra time.

As a Business Analyst, my advice is to...

[ninejaguar]

...give him what he needs, rather what he asks for. If he looks at a competing website, and thinks that it is "exactly" the same as what you're doing, this is a classic case of failed requirements gathering. For one thing, he obviously doesn't know what you're doing for him. Another thing, if his comparison of that other site to yours is puzzling to you, you obviously don't have his full requirements.

Obviously, if you just give him the same thing as what that other site presents, he'll regret it. And, you'll regret it as it probably doesn't really cover his needs. You need to find out what he needs. Then, present it to him as a clarifying document so that he can see what you're doing for him, and if he agrees with it.

Use that other site as a base and start talking to your client about what he finds good about it. Then, find out what he finds missing in that site and yours (if you have something he can see). To fill in the puzzle of his needs, you need to pump him for requirements, and avoid giving him more sugar than he can handle. It wouldn't hurt to put together a diagram of his business process pertaining to the site. But, if you think it's overkill, at least put together a Functional Specification (really just a list of things he needs the site to be able to do) that describes what the site should do as part of his business. This can be the beginning of a contract that you and your client can come to agreement on, and anything else outside that contract is out of scope until the next revision. This will reduce some of the annoyance in dealing with a none-technical person who also happens to hold the purse-strings.

= 9J =