Vendor Capability Requirements

When contemplating acquiring software from a vendor, it is important to understand how the capabilities of the organization that you are purchasing from add value to the project, and to the product and your business process over the life of the system. Here are some typical capabilities that vendors provide:


  • Software maintenance and enhancement – One of the primary values that purchasing software can provide, are continuing updates and enhancements that the vendor makes to maintain the marketability of the platform. The vendor is under pressure to continue to sell their product to new customers, and therefore must keep the product current and competitive in the market place. You benefit from this because by paying a small annual maintenance fee, you are “entitled” to receive software updates.
  • Support Services – No software is free of defects, and certainly every customer of a software vendor will have continuing need to inquire about capabilities of the software. This is typically negotiated as part of an annual maintenance or support agreement through which the customer pays to have the vendor available to fix issues with the software, and answer questions about the software.
  • Implementation Services – When installing a software product for the first time there is usually a project to “implement” for each customer. Many customers will pay hourly rates for experts from the vendor to assist them with the implementation of the product. These services can involve analysis, project management, technical installation, and other services.
  • Integration Services – If you intend to connect the purchased software product to other systems in use at your organization, often the vendor will participate in building of the connectivity. Many vendors will have pre-existing integration and perhaps partnerships with other vendors in related vertical markets – as well as capabilities to construct bespoke interfaces to systems proporetary to your organization.
  • Hosting Services – While this is relatively recent terminology, it used to be “Service Bureau” where the software actually runs an hardware/network infrastructure that is owned/contracted by the software vendor. While this is certainly convenient for smaller organizations that have limited integration requirements – it can present challenges for organizations/systems with significant integration. Focus on platform support – as a separate service from product support, and availability/recovery/business continuity as capabilities of the hoster. Service level agreements for infrastructure problem resolution are typically much shorter than for software problem resolution.
  • Bespoke Customization Services – Customers that take advantage of these services, are actually outsourcing their software development. Many organizations with little or no capability of their own find this attractive, and if there is also no capacity to develop requirements, manage projects, or test the resulting product, one is completely reliant on the vendor. Different vendors have different approaches to this – some refuse to build and maintain custom software capabilities that are not “generally releasable” or valuable to the rest of the client base. Others may have another “services” practice that maintains a separate development/project organization around these opportunities. Still other vendors maintain a set of tools or building blocks at the core of their software product(s), that they also maintain a practices of using to solve problems for clients on a consulting basis, or even that they sell these tools to other companies that build product in other vertical markets (not to competitors). Utilizing bespoke customization services, requires that the service be in the best interest of both the customer and vendor, else customer can find themselves unsupported after a warranty period.

Understanding what capabilities you will require from a software vendor is a starting point. Of the capabilities listed here, the hardest to write requirements for is the last. It is extremely hard to assess how capable another organization is at delivering software capabilities.

Starting with an understanding of which capabilties you will request, you can ask potential vendors for their standard policies/contract terms/rates. You can ask for references from customers that have utilized these services in similar ways. My experience is that most vendors who are hungry for new business will over-sell meaning they will promise things that they cannot easily deliver. Ask for examples of similar projects with references and examples of work product. Companies that are restrictive – that want to dictate terms, often are less interested in growing their customer base – this may indicate that they do not find you an ideal customer, or that they are not marketing the product you are interested in agressively. This may indicate that support or supportability of the product is waning, investigate the viability of the company, or the risk of mergers and acquisitions.

Your vendor requirements should contemplate the life of the software product in your company. If your plan is to use it for 5 years, you need to understand the vendor’s 5 year plan. You need to understand the software product and it’s customer base – if you are not close to the center of the customer pack, there is a strong possibility that the rest of the customers will move away from the direction that you are going. Make sure that the product roadmap is in alignment with your near term goals, and the vendors financials will support them being in existence for the projected duration of your reliance on the platform.


  • Anonymous

    July 7, 2011 at 2:45 am Reply

    Rich. Great Article. Currently evaluating software vendors and this give a different prespective.

  • Rich Stone

    July 7, 2011 at 3:46 am Reply

    Thanks Gyan, good to know it was helpful to you.

  • Rich Stone

    July 7, 2011 at 3:48 am Reply

    check out this link – is a list of related posts on this blog:

Leave a Reply