Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Why spreadsheets don't cut it for enterprise software evaluations

Chris Doig | Aug. 21, 2015
Is your evaluation spreadsheet tying you up in knots? See why spreadsheets don’t deliver when evaluating enterprise software.

Evaluation spreadsheet tying you up in knots?

Enterprise software evaluations often start out as spreadsheets but soon run into problems. Why does this happen? For the same reason that accounting systems don’t run on spreadsheets: spreadsheets are too manual. They don’t scale up to handle the many hundreds or thousands of requirements found in a typical enterprise software evaluation.

The scaling problem is familiar to people in growing companies. Systems that originally worked well begin to fail as they are scaled up. Likewise, spreadsheets that worked well when starting an evaluation struggle as the number of requirements grows.

Evaluating enterprise software is a lot of work. Managing this work in a spreadsheet seems the obvious choice, but that is deceptive. What many people don’t realize is that at the enterprise level, they will end up building a complete evaluation system in a spreadsheet, which is always far more work than expected. In this article, we look at the limitations of using spreadsheets to evaluate enterprise software and conclude with suggestions.

Limited cell formatting

To select best-fit software you need well-written requirements. Formatting and text size limitations of spreadsheet cells are real problems. Also, Excel and Google spreadsheets limit you to one link per cell. In reality, you sometimes need more than one link:

  • When writing requirements, rather than explaining acronyms and terms used, you may want to include inline links to external references like Wikipedia.
  • When rating a product against a requirement, you might want to include links to pages in an online manual and links to videos explaining that feature.

In spreadsheets you can only have one link per cell; you can’t add inline links to words or terms in the cell text. As a workaround, you can add extra columns to the spreadsheet but this can get unmanageable very quickly.

Limited data structure

Relational databases have the concept of normalized data, where each data item exists only once in the dataset. Denormalized data is where multiple copies of data items are used. The problem with denormalized data is that when a data item is changed, it must be found and manually updated in multiple places to keep everything consistent.

The limited data structure of spreadsheets means that multiple copies of data are inevitable. Keeping everything consistent is difficult if not impossible. This flat and non-relational data structure is a core problem with spreadsheets.

Denormalized requirements

Spreadsheets usually start with all products on one tab, but limitations quickly lead to a separate tab for each product being evaluated. When you consider that every requirement on an evaluation should appear on a master list, and again on a tab for each product being evaluated, the problem of manually updating multiple requirements starts to become apparent.


1  2  3  Next Page 

Sign up for Computerworld eNewsletters.