1) Footprint. We already run a number of things on the client so we want them to be as lean as possible. Where possible we stick with the same vendor since they are more likely to combine agents and lower the overall footprint.
2) Dependencies. The more we install on the client the more we have to juggle when things upgrade or delay upgrades. A common thing is to see if this requires a specific version of Java or .Net.
3) Management of the software. Can it tie into anything we already own for management? Does it integrate with other systems for layered security? Or is it just another silo?
We are big proponents of having as few vendors as possible and helping them refine their products over time to meet our needs. In the end I think these things help everyone. The end users get something that works well and is unobtrusive; the help desk gets something that doesn't break as often, the IT analyst gets something that integrates with what they already know and Management gets a generally less expensive product since we usually get bulk license discounts (for owning a lot of software from that same vendor).
Sometimes we get software that doesn't do everything we want, but we are okay with that if the vendor is honest and willing to implement the other features. It's not uncommon for our IT shop to be told something can't be done by the vendor that built a product, then prove them wrong. Because of that we don't expect most off the shelf software to do everything we can think up or plan to do with it; but if the vendor is willing to work with us we'll gladly be their pilot site.