Agile Zone is brought to you in partnership with:

Pete Johnson created one of the first web applications ever built inside Hewlett Packard during the mid 1990's and has had the good fortune to work with over 400 engineers all over the world, write articles for a variety of publications, and present topics at trade shows. He served as the HP.com Chief Architect for two and a half years before a reorganization brought him his present responsibilities as the Marketing and Internet Platform Services IT, Portals and Applications Chief Architect (try fitting that on a business card). Pete has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

The Software Sales Pitch - Choosing Wisely

02.10.2009
| 11914 views |
  • submit to reddit
It's a common tale:  Some business need arises for capability your IT department doesn't currently offer but there are multiple commercial alternatives available and maybe even an open source solution that can help you fill your gap.  Then again, you could always write the thing yourself.
Build? Buy? Both?

Here are some ideas that might help you decide.

The vendor sales team: Please give us your money

Every 3rd party vendor has a bunch of really nice people with friendly smiles and company issued button down shirts.  While they likely have great technical expertise and are easy to get along with, make no mistake about what their job is: to get you to spend money.  It actually seems like a pretty neat job, you just sometimes have to take statements these folks make with a bit of skepticism.

The typical initial presentation this group will give includes an overview of all the cool features their product provides, an architectural layout of a basic installation, and a slide showing an explosion of company logos representing their install base.  While this is a nice starting point, these first conversations rarely go into enough depth to allow you to make an informed decision.  It's a good idea to get a round of these from all the vendors you are considering before going deeper with any one of them.  For open source or build from scratch alternatives, create a presentation that goes to the same level of depth so that all possibilities are given equal consideration.

How do you go deeper in a way that will let you make a decision?

Building assessment criteria: Spreadsheets abound

Start by listing out the requirements that each group that will be involved in running the end solution has.  Business constituents will likely have a list of features, IT staff might enumerate specific technologies they may or may not want, support could want to know about logging capabilities, and management may worry about the financial stability of the vendors being considered.  Think about the different lifecycles of the various parties involved and total implementation costs (machine acquisition and any post-sales consulting) as well.

Inevitably, your criteria will get placed into some kind of spreadsheet scorecard that can be used to objectively measure the different options against one another.  Each criterion gets a row where it is scored with some numerical range and weighted relative to it's overall importance.  The decision makers in your company fill out scores after each detailed vendor presentation and whoever scores the highest wins. 

While this approach is a good one to take it's important to remember that it is a guide, not an absolute measure.  A spreadsheet like this can help synthesize large amounts of information for easy viewing but that doesn't mean that the weightings or scoring are perfect or that non-quantifiable criteria might lean your decision on way over another.  Be sure to bring along a healthy dose of common sense when it comes time to make a decision.

With criteria in hand, how do you go about getting enough detail from the vendor to score it?

Use Cases and Being a Little Mean

If you simply hand over your criteria scoring spreadsheet to the vendors and say, "Can your product do this?" the answer will either be "Yes" or "It's in our next release."  A better approach is to look at your criteria and come up with step by step use cases that represent as many as possible.  Then ask the vendors to demonstrate how each scenario can be accomplished using their product.  You still have to look out for the "It's in our next release" answer, but you'll get a deeper look at the product.

Give the vendor very little time between when they see your use cases and they demonstrate how each is fulfilled with their offering.  This prevents some behind the scenes magic or that "special beta version" from appearing during the demo that just happens to meet your exact need but isn't in the full release yet.  Shrinking that window of opportunity puts extra pressure on the vendor sales staff to come up with a demonstration, but you get a truer picture of the out-of-the-box capabilities.

Summary

  • Remember that those nice vendor sales folks are trying to sell you something
  • Think about different lifecycles and total deployment cost when creating your assessment criteria
  • A scoring spreadsheet is nice, but not a complete substitute for common sense
  • Build use cases from the assessment criteria and give vendors very little time to implement a demonstration to get an accurate reading on what their product can do
Published at DZone with permission of its author, Pete Johnson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andrew McVeigh replied on Tue, 2009/02/10 - 3:43pm

If you simply hand over your criteria scoring spreadsheet to the vendors and say, "Can your product do this?" the answer will either be "Yes" or "It's in our next release.

Too true.

Remember that those nice vendor sales folks are trying to sell you something

Again, very true. When you buy, be very, very careful because often salespeople will distort facts and promise the world to make a sale. Make sure you dive into the technical details and absolutely do a proof of concept before buying. Particularly when it's a big sale. Actually sit down and develop against the product to 100% ensure it does what you think it does. Spend all the time you need to know it does what you expect and want.

Sadly, i've seen too many people lose their jobs after recommending a package or a product and then having it go bad on them. They find out too late that they were oversold.

Andrew

 

 

 

Guido Amabili replied on Wed, 2009/02/11 - 6:02am

 

Sadly, in our company,  people having the responsability to choose the software for a particular job are non-technical people.

We are becoming third party vendors bc what they are trying to sell us is lock in software with no additional values.......

But the guy is happy to think he doesn't rely on the IT Department.

Thinks he doesn't need our knowledge, I just want to leave.

Jeroen Wenting replied on Wed, 2009/02/11 - 6:53am

Guido, it only gets really painful when you're an IT company and the guys in management think they want to not have to rely on the IT department to make the products your own salesteam is selling...
I've been in that unenviable position. When the CEO of a software house that sells software they write themselves (and custom modifications on that software) starts making statements about the company being "service oriented" rather than "product oriented", run for the hills.
The next phase (which we experienced full blast) was that everything that goes wrong is blamed on you, the technical people, while every success is showered onto the sales people and non-technical staff (trainers, mostly, in that company). This went so such idiotic extremes that we were blamed (as software developers) for downtime at a customer site that was caused by a power outage at that site which wasn't covered by the UPS the salesteam had failed to sell to that customer despite being recommended by our hardware team. A while earlier the salesteam had been applauded for selling a product despite us warning them that we would need at least twice as much time to build it as they had promised the customer, we ended up being blamed for being late to deliver when we delivered well short of our original estimate (which the sales team had completely ignored).
After a few months of that I'd had enough and left.

Mark Unknown replied on Wed, 2009/02/11 - 8:31am

Guido,

 To add to the gloom - those users end up needing to have you support what they bought. 

  I am facing this right now. I was pulled from a small external business unit (it was disbanded) into the larger organization where the mentality is buy vs build and "technologists" are not valued - unless you are a manager or above.

 

 

 

Jeroen Wenting replied on Fri, 2009/02/13 - 12:52am

I'm all for buy vs build (especially in a non-IT organisation), in principle.
If there's an existing product (especially if it's a mature one) on the market that does what you need done, it's far less risky to adopt that than it is to try and reinvent the wheel. Even if what you need done isn't matched exactly by an existing product, it's often better to change the way you work than it is to try and make something that fits your practices exactly. Those existing products work differently for a reason, and that reason may very well be that that way has been found by a range of users to work better than the way you're doing your thing now.
Of course if your shop is highly specialised it's quite possible that no COTS exists that can be adopted, and chances are none exists that can be adapted, leaving building (or contracting to have built) the only viable option. But if an existing solution exists that can be made to work for your organisation, that's almost always the best option (both in direct cost and risk).

john green green replied on Sun, 2009/12/06 - 11:35am

While this is a nice starting point, these first conversations rarely go into enough depth to allow you to make an informed decision. It's a good idea to get a round of these from all the vendors you are considering before going deeper with any one of them. For open source or build from scratch alternatives, create a presentation that goes to the same level of depth so that all possibilities are given equal consideration.
nike china shoes

Knight Sukn replied on Thu, 2013/07/25 - 4:28am

There are a lot of trick and techniques that sales vendors use, my cousin worked for a software company and told me about their selling techniques. He helped me to find a dress for my daughter at game day dresses and explained me why a lot of people choose their products, it`s all about their marketing team that managed to advertise their products in an unique way.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.