DID YOU KNOW THAT:
Deciding how to pick a vendor is almost more important than deciding which one to pick
Some projects are doomed from the start because they don’t get all the decision-makers lined up on how product and vendor decisions will be made. As a result, the product choice that is eventually made doesn’t have the full support of all the stakeholders—and the project fails as a result.
Mpower Group Chief Executive Officer Dalip Raheja says his firm does a lot of work up-front with customers to design a decision process, which should include interviewing the decision-makers individually to lock down what it will take for them to decide in favor of a product, and how important each of their requirements are to them. The chief financial officer, for example, may have specific cost-of-ownership considerations while the CIO may be more concerned with vendor viability.
Identifying decision-points early and agreeing on the importance of each factor eliminates most of the contention once the decision process begins, creating a “single vision” of the organization’s goals.
What most people decide first should often be decided last
Many times, companies let their existing relationships drive the product selection process. For example, the integrators are involved in the request-for-proposal process, and as a result the products chosen might be those that play more to the integrator’s strengths (and existing relationships with vendors) than the customer’s needs—and that could mean the project will end up costing more, or taking longer, or not succeeding. Raheja says that companies should select their application software first, and then their hardware vendor, and only at the end should they select integrators to help them where assistance and outside expertise is required.
If you don’t assign a business value to technical specs, they’ll get lost in the translation
Technical issues, like ease of integration with existing applications and support for a preferred set of development tools, may be key to the long-term success of an application project and affect the ability of the company’s in-house developers and technology staff to maintain and sustain it after its completion. But if the technical side of the decision-making team wants its concerns about architecture, integration, and other specifics to be given weight in the selection process, those requirements will have to be translated into business benefits so they can be easily understood by everyone on the team. While a line-of-business manager may not understand software architecture, for example, the issue will be a lot clearer if it’s translated into the total cost of ownership of a candidate product based on how much additional work will be required to integrate and maintain it.
You shouldn’t just do product comparisons, you also should do company comparisons
There are several ways to benchmark vendors, including per-user and per-server software license prices, per-user support rates, and maintenance and upgrade charges. But be careful. For integrators and consultants, the benchmarks aren’t as cut and dried. There may be a temptation to look at integrators and consultants using something like the average billing rate—the average amount per contractor per hour that they charge.
But Todd Schreiner, a senior manager at Mpower, says “that benchmark can be misleading.” An average billing rate, he says, is only helpful when all project-development factors are the same. One integrator, however, might propose four developers for so many hours, while another might say it needs one manager and three developers for so many additional hours.
