I get a little strong-willed when it comes to doing things the right way. (Read: "Pimp slap.") Whether it's telling a company they *need* a development server and can't get away with a super-secret directory on their live Web server or informing someone that finding a company willing to do your bidding does not constitute "market research," I'm willing to put it out there that certain levels of effort are unacceptable. After all, the whole "it costs money to make money" thing surely crosses over to, "it takes time to save time," (bear with me) and, time=money being a given, you need to invest time in proportion to the money you wish to save or make. Right? Well, maybe that's too convoluted now that I think of it, which may be why it takes a little while to convey these points. I'll work on it.
Anyway, I got an email from somebody today who was looking to investigate his company's alternatives to a current email marketing ASP ("outsourced application", to all of you business folk). The first step? Have the current vendor in, before all of the users of the current tools, to pitch their next-generation solution(s). Never mind that there are ongoing issues with the current product, this demonstration would serve as this company's baseline for future requirements for applications of this type.
Now, I'm no Harvard MBA... but shouldn't you sort of figure out what you *want* to do, then try to find a product or suite to accomplish that business goal? I understand to a point just needing to know what *is* possible with any product. That's market research, reading product slicks, having calls, etc, etc. I also understand that a lot of business users are of the consumer-oriented "deliver me a product to start using tomorrow!" mentality, but this was a seasoned IT person. No kidding. Let the current vendor - with the awful API and really bad implementations - set the stage for Round Two.
I emailed him back, upon learning of this approach and said something to the effect of, "learn what kind of features you want in a car before you drive your car to the dealership for a trade-in... you may just want a different kind of car." Man, my analogies are weak these days. Anyway, Horse precedes Cart. Requirements precede Vendor flying in for the day. It's possible to do this with a cross-functional team without a waterfall approach, but even that doesn't change that defining the business need always precedes a gap analysis. I don't care where you went to school.
ED. COMMENT (16 Jun 2008): I got some offline backlash for this post from somebody familiar with the situation. I guess my blog is more widely read than I thought. They cited routine vendor management, good practice, no current project, blahblahblah, but it was still - I maintain - awfully bad form to ensconce vendor management in defining the baseline for future requirements (in no uncertain terms!) based on what one vendor has to offer. That's how companies head down tunnels, and this is no exception. Talk to a vendor all you want, but to prep your business audience with language that invites them not to do any market research - but to rely instead on what this sole, trusted vendor has to say - and you're doomed to repeat some mistakes.
0 comments on Carts & Horses