Current Articles | RSS Feed
Let me explain the dilemma of these choices more thoroughly:
Proponents of the former argue that even though requirements aren't defined, in today's dynamic business environment the requirements change as often Paris Hilton's BFF, so the requirements aren't that important if not just loosely defined. Plus, assuming the solution provider can demonstrate domain expertise, they can help shape the implementation to optimize your instance using their wealth of best practice experience.
Conversely, proponents of the latter make the point that it would be difficult to truly evaluate the value of a given solution to one's organization without clearly defined selection and performance criteria-especially if there is a buying committee tasked with making the final decision. Otherwise, one never really knows what their getting until it's too late.
Interestingly, my own informal pole on the subject among what I would think would be highly qualified individuals (as highly qualified as you can be at a cocktail party, anyway) indicates that there is pretty much an even split between the two philosophies. Frankly, I'm surprised by that polarity....although I shouldn't be, because I have made sales under both scenarios in my career-even purchases dare I say. However, my best advice (not that you asked) clearly falls in the second camp-define your requirements first. That's just my opinion, mind you, but I'd be interested in hearing yours.
0 Comments Click here to read/write comments
All Posts