Information Technology Reference
In-Depth Information
alone. Sometimes, interfaces to such nontechnical infrastructure are
showstoppers.
Understand the implementation life cycle and the risk matrix
. For
example, data migration is an important aspect of bringing in a
new package, the complexity of which is often underestimated.
. They can provide valu-
able input. Have your technical staff talk to their peer network
who might have worked on such packages. Talk to reference
customers who have used the OTS product in environments similar
to yours. Talk to interview candidates whom you may be planning
to hire for such projects; interviews are a good way to obtain
information.
Develop informal sources of information
Having trial runs is not simple, as most packages require some
customization and considerable configuration; however, do not rule
out the pilot (proof-of-concept) project — there is much to learn
when you see it working in your environment with your data
.
However, it is important to dedicate the right resources and time
for such trials. If going for a pilot, do it right. If it is done for
namesake only, serious impedance mismatches may be discovered
after purchase.
Avoid checklist-based requirements.
You are buying a solution, not
a list of features. Checklists come up against the understandable
reluctance of vendors to say no to any of your requirements as
long as there is some wiggle room. Both you and the vendor could
mean perfectly different things for the same requirement. The
solution is not to go on being more detailed until every last nuance
is nailed down, but rather to look for signs of evasiveness in the
answers from the vendor and to demand clarity.
Similarly, avoid checklist-based prioritization of the list of features
(Figure 9.2). Prioritizing vaguely worded requirements can be a
recipe for disaster.
Be aware of the constraints in your organization's environment
.
Things that the OTS vendor may be taking for granted may be
unheard of by you. They could be related to hardware or software
infrastructure, networking bandwidths, user skill sets, or even cli-
matic conditions. Most implementations of perfectly sound OTS
software fail because certain key constraints are discovered too late
in the delivery life cycle.
Do not assume that the vendors have the required experience in
implementing their own product
. They may know it better at an
internal engineering level but the implementations could have been
left to outside certified consultants.
