As a follow-up to Vendor? entry -- otherwise known as I Tried So Hard To Be Your Best User Yet You Lied to Me in The End -- this somehow feels anticlimatic. In between we've had a pasrah tester, three guys whom noone seems to know, a PhD candidate who won't mind conquering Mt. Everest for fun, stairway stories AKA Boni's misery, a restless widow, and many more. But a promise is a promise. So here goes.

Let's start by defining a few terms first, shall we? By vendor, I mean a project manager or a functional lead or a system designer that interacts directly with customers. BTW, I tried to find a better term 'cause vendor just sounded so Singaporean -- just like I psycho him and can I dun come? -- but found no love. So vendor it is, then. By customer I mean a director or a manager or a user that supposedly wants to benefit from the application. By user I mean a person who uses the application directly, not a manager who shouts, hey you, print me that report and tell me the figures, will ya. By application I mean a computer application that is the final product of this whole exercise. All right, y'all clear? Good, 'cause this might come up during the final paper.

Earlier on (read: 9 days ago) I gave a basketball-match analogy to help explain this bittersweet relationship between a vendor and a princess -- I mean another person -- that was his/her customer. You can be friends outside the court or you might despise each other with the burning fire of a thousand nuns. Yet when time comes to play ball, play ball you do. You play hard, you try to outscore your opponent, you want to win and make your country -- or that pretty thing on the third row -- proud.

While in real life, I dare say, the analogy is accurate most of the time, it's not what it was meant to be. I mean, come on, shouldn't the vendor and the customer be working together to make a useful application? The vendor might 'win the match' by producing a low-quality application that costs peanut to build yet looks like wo and costs the customer Schumie's yearly salary. The customer might 'steal the victory' by ending up with a sophisticated application that has tons of features yet costs zip. But what good is an application that seems able to do everything if in the end 70% of that 'everything' is wrong? What good is a 'good' application if in the end only 5 features out of 20 are really useful and indeed used?

I have a dream that one day a vendor and a customer will sit side by side and together design and implement a dream application that brings smiles to vendor and customer alike. I have a dream that one day no more "You have to do this and I don't care what it will cost you because I have mentioned it since day 1!"s and "You have signed off the functional specs, now live with the consequences and I'm not gonna do anything unless you pay me more!"s will be heard in status-update meetings.

Since a dream seldom comes true, at least in my case, I will now land back on earth and deal with the rest of the issues raised in the original post. Let's see, what do I, as a vendor, want from my users... First, in general users would be less knowledgeable than I am in this application that I'm developing. Or else they would be the vendor. So it's OK for users to ask innocent (read: stupid) questions, I have no rights to complain and must explain until they understand. So long as you don't ask me three times a day which menu to click to login or whether you should power up your puter first before using the application, we're cool.

While I know more about the application, users know more about the business process, so I should listen to them. To a degree. Whatever dreams I have, there will never be an application that doesn't require compromise. So I expect my users to be reasonable and open for suggestions. Don't tell me it has to be done this way. I'll do my best to accommodate your needs, but I have my project schedule to follow. You don't want me to fall sick or go insane trying to do it this way, do you? Because then you would have to re-live this painful experience all over again with a new vendor.

On the other end of the scale, there are users who can't be bothered -- to borrow more Singaporean fav words -- about the application until it's time for them to use it. That's when all hell breaks loose. I'm trying to help you do your work more efficiently, so help me help you. Invest time to gather the requirements and test the application. Believe me, I know how busy you are. After all, if you were not busy, why all the fuss to have this application developed?

I know how 'some vendors' like to twist your words and avoid doing what they have to do, but hey, believe it or not, there are some good, honest vendors in this planet still. Just like not all guys cheat on their SOs although 2 in 3 do. Was that stat ever valid, BTW? Some appreciation and understanding now and then won't hurt, either. We vendors are human -- yup, no matter how weird we appear sometimes -- too, you know. We make mistakes. Just like you users make mistakes. Although the rule of thumb says, customers are always right.

Oh, and giving your vendor some Ferrero Roche is not a bad idea also. Your vendor might in return give you some dodol when he's back from a trip home. Not a bad deal, especially now that dodol comes in as many flavors as ever.

Well, I guess that's enough vendor-talk for one night. I still have to play vendor tomorrow and my bed is starting to miss me. So there. Love your vendor and make jeans not war.