Information Technology Reference
In-Depth Information
One is expected to build on that base. Working with someone else's less-
than-transparent creation with the intention of modifying it can make one
feel that one's hands are tied or that one is working in the dark.
Customization follows an authorization to make changes given to you
(the customer) by the product designer. The nature and scope of changes
that are allowed to be made are part of the product design. You, as a
customer, can control customization's content but not its larger scope. You
must operate within the playing field according to the rules set by the
designer. This scope, however, may change over time as the base product
evolves. Things that would have had to be customized in an earlier version
may become part of the base product in future releases.
A question that often arises is: what is a “good” percentage for the
degree of customization required? That is, what should the ratio be
between what is in the box and what needs to be customized? The
customer would like to get as much as possible out of the box. Vendors
would like to suggest that the customization needs are minimal. There is
an argument that if the percentage of customization required is too high,
buyers will consider developing the application themselves. The talk of
percentages is a red herring. The very nature of business precludes such
generically applicable ratios even for highly structured domains such as
accounting. Each product has a different degree of effort, expense, and
benefits associated with it. Before one starts quantifying the efforts,
expenses, and benefits, one must decide on the customization objectives,
for example, saving time, avoiding effort, ensuring quality, bringing in
new technology, etc.
Customization Requirements
Customization requirements (Figure 10.1) are fundamentally delta require-
ments. This delta is between what the package provides and what you
require. Determining both is difficult. If one knows what one requires,
then determining what the package provides may not be easy, especially
in a pre-sale mode. Ironically, at times, knowing what one requires also
can be the problem.
What are delta requirements? In one sense, all requirements are delta
requirements. When developing an application from scratch, the delta is
between what exists (nothing, something manual, or another package)
and where you want to be. When you are customizing an OTS package,
the delta is between what the package provides and what you want.
As in any purchase or sale transaction, both being two sides of the
same coin, there is necessarily an unequal distribution of information
about either side. The vendor knows the product but not the customer's
