Continue in 2 seconds

Closing the Gap Between Project Requirements and Product Feature Sets

  • January 21 2002, 1:00am EST

Editor’s note: is proud to welcome Dan Meers as a new online columnist. His Consultant’s Corner column will present fresh ideas on total cost of usage, best-of-breed consulting, various aspects of the Corporate Information Factory and strategy for aligning business and IT. Check out Dan’s presentation, "Measuring Your Total Cost of Usage," in conjunction with the online trade show Using BI to Unsnarl Data Management Gridlock at

If any of these vendor promises sound familiar then this column is something you may enjoy:

We can do that….

Our proof of concept will demonstrate that…

That is included in the Enterprise Edition…

Or – perhaps the best of all – You don’t really need that.

One or more of these "assurances" has been the less-than-complete answer to our questions during the process of considering products and vendors. We are often given every assurance imaginable and left to ponder the results of a series of demonstrations and proof exercises. Our experience invariably leads to more work and frustration when decoding product specifications, customer referrals and proof results. Vendors are slow to change in the face of customer frustration. Customers, on the other hand, are much more nimble and adept at changing their approach to the purchasing process. RFQ and RFP processes have changed dramatically over the past several years, and now vendors are seeing very different demands for demonstrations and proofs. We will consider some of these changes and highlight the benefits for the well-informed customer.

Feature-and-Benefit Selling

Thanks again to IBM for codifying this bullet-point approach to selling everything from application software to processing platforms. This approach was a step forward, at least when first introduced during the late 1960s and early 1970s. Feature-and-benefit selling does attempt to map product features to business benefits, albeit in a generic way. Our ongoing reliance on this approach is a testament to its functionality. It is a good way to consider basic product comparisons but leaves huge gaps in critical areas of project alignment. It also allows vendors to shape too much of the conversation and direct the comparison process. The feeding frenzy of vendors seeking the pole position in your product comparison process is the direct result of this selling approach. The first vendor to gain consistent access to a decision- maker often enjoys the luxury of setting the terms of comparison. Buyers are usually clear about their priorities but less than clear about translating these priorities into product features. Consultants can improve on this process, but only to the extent that they consistently employ a methodology that is meaningful and appropriate to the customer. Even those customers relying upon the guidance of a consultant tend to question vendor representations that lie outside the scope of the consultant’s expertise or opinion.

Process Selling

This approach to the adoption of technology has been developed around large-scale or systemic projects. Applications including MRP and ERP hastened the adoption of process selling. "Intelligent storage," "industry analytics" and "Web analytics" are examples of recent hybrids that rely on process selling to distinguish their potential to an enterprise. Process selling is often aimed at defining a whole new category of need by customers and then selling to it one project at a time. Process selling can be very meaningful for customers but has been limited to very large-scale purchasing prospects by the vendors. While the largest vendors with the most expensive and expansive products have honed their process selling skills, few if any mid-sized projects benefit from this focus. This is even true in customer sites engaged in the purchase of a process-based system. Many customers are adopting ERP or intelligent storage systems and are simultaneously being barraged by the same vendors and their partners with feature and benefit comparisons of integrative technologies. Issues associated with the project charter and project sponsorship level often impair the customer’s ability to drive vendor-selling efforts. It is important to provide vendors with enough selling opportunity to justify the additional effort involved in process selling.

Message to Vendors: Stop Selling Products, Start Selling Process

Customers would appreciate the opportunity to frame their purchase decisions with the scope and parameters of their projects. Projects fund technology acquisitions so the more focus that is given to the project opportunity, the more success vendors can expect to have in their overall sales performance. Vendors do have the right to expect clear access to decision- makers and implementation resources as they mold the process solution. Vendors may also expect clarity and timeliness of access to project parameters and selection criteria. It is important for any vendor engaging in process selling to understand the scope of this activity. Process selling must not decompose into a constant barrage of features hype and product positioning in an effort to solve any potential problem associated with the project. Customers will expect to see specific product application to their project needs with limited mention of additional functionality that will impact enterprise success. Each project will require a different level of care and scope, the top sales and engineering resources in your company will recognize these limits and respect them in order to foster trust in the process selling initiative.

Message to Customers: You Are Right

You’re instincts about demonstrations and proofs are dead- on. You are also in control, much to the chagrin of your sales executives. I know from firsthand experience that most of these sales executives are actually interested and willing to take on the effort of some process-based selling initiatives. Many are already insisting on holding proofs at customer sites with customer representatives looking on throughout the process. They are also willing to get internal contacts familiar with the problems associated with your type of project on the line to discuss specific solutions. It is important that you give these vendors clear and consistent access to the project owners and managers and that project parameters be spelled out clearly. Customers can expect to benefit from a more focused purchase cycle and from the realization of business benefits more tightly aligned with project requirements.

Process Selling Example

Recently a customer asked about the adoption of an ETL tool to drive the creation of a multi-subject data warehouse. They had originally tried the direct-to-mart approach with limited success and major cost. They realized that they were unable to reuse any of the components of their hard-coded solution and that additional subject areas would make the approach untenable. ETL tools looked like a good way to jump- start their efforts and provide reuse and other important benefits. They had attended presentations on tool selection but found the features comparison lacking and wanted to tailor their selection process to the project parameters. We agreed on a process approach and took the time to "white board their environment to identify critical process requirements. This provided a set of requirements that was far more revealing than any feature set could provide. The roles of meta data, process, data and information quality and application maps and data models were clearly illustrated and evaluated. This exercise took less than a week but paid big dividends.

The next step was to create a specification for the process requirements. This was written based upon the project and enterprise needs, not the features and benefits available from ETL tools. The resulting document drove the RFP and set the stage for a customer-driven look at vendors and products. Demonstrations were permitted as were various sales calls and technical conference calls. Customer referrals were accepted subject to confirmation after all other reviews. No proof-of-concept exercises were used, instead, a project validation was held for vendors to apply to their products and services. Each vendor was given the same subset of processes to address, either with their products, with third- party partner products or a call for customer action or best practice. Vendors were told in advance to specify how they were addressing each process requirement.

Figure 1: Process Requirement Matrix

Process Requirement Vendor #1 Vendor #2 Vendor #3

Data Sourcing

Internal function

Vendor add-on


Meta Data Origination

From sources

Internal function

Best practice (DIY)

Process Management

Internal function

Internal function

Internal function

Information Construction

Internal function

Internal function

Internal function

Parallel Processing

Third-party add-on

Vendor add-on


Quality Monitoring

Best practice


Internal function

Meta Data Exchange



Open – Best practice


At first glance, many of these requirements seem to be features, but note the use of descriptive answers rather than yes/no. The project validation included careful testing to identify the methods employed, complexity of usage and interaction within each tool and its external or add- on components. Missing or weak process functionality was evaluated to determine the costs of resulting process gaps. In the end, a total cost of usage (TCU) matrix was compiled to compare the likely "life cost" of adoption for each tool. This matrix was drawn from the process requirement matrix (See Figure 1) and used to highlight the gaps that each tool would leave for the project team to fill. The final analysis came down to decisions about what types of gaps the project team felt most comfortable closing and the impact on reuse of the tool for future iterations and projects. This approach is based on activity-based costing and is known as the "total cost of usage." TCU can be an invaluable means of identifying the real costs of a project and the tools selected for adoption. TCU is also a highly effective means of communicating process based project costs to all levels of management.

A variety of more detailed milestones of a process sales initiative will be shared in future columns. I wish you "better luck this time" in your project.

Dan thanks Bill Inmon for his guidance and support in the development of TCU practices.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access