Page 332 - Untitled-1

INFORMATION OVERLOAD 311

Selection should be made on the basis of the large picture. Consider connec-
tivity to other systems. Consider both current and future needs. Avoid political
decisions, such as choosing a product because you would have less risk of criti-
cism if the solution failed. Look for ways to bridge the normal chasm between the
projects and the operations functions.

Don’t concentrate too much on software cost. Most tool solutions represent
but a miniscule part of the costs of doing projects. But do consider life-cycle
costs. How much will it cost to operate the system, say for five years, including
software, hardware upgrades, and training?

Don’t get caught up in little details. Look more at what you need to accom-
plish with the software, rather than at the feature set. A recent Dilbert cartoon,
by Scott Adams, pictured someone presenting a desired feature list of several
hundred items. When questioned as to the potential effect of such an expan-
sive list on the usability of the software, he responded, “Oh! Let’s add ease-of-
use to the list.”

There will need to be a balance between the expanse of features and ease-of-
use. But here are two things to note about this. First, due to differences in prod-
uct design, some products will be easier to use than others, even when having
similar functional attributes. Second, expect all PM software products to be com-
plex. They will not be as easy-to-learn or easy-to-use as word processing or
spreadsheet tools because the typical user will have to learn many new things
about planning and control in addition to learning the new tool.

Information Overload

Over the past 15 years, I have written, taught, lectured, and consulted on the
topic of Specifying, Evaluating, and Selecting Project Management Software.
This includes a formal seminar, a book Project Management Using Microcomput-
ers (Osborne/McGraw-Hill, 1986), a chapter on that topic in David I. Cleland’s
Field Guide to Project Management (VNR, 1998), and a video produced by IBM’s
Skill Dynamics.

In my enthusiasm to fully cover the topic, I more often than not got carried
away with details. This compulsion to cover every aspect of software selection and
use may have been technically sound, but, in retrospect, may have failed to have
the desired effect. I may have made my audience more knowledgeable and aware
(an important objective), but did I leave them in a better position to make a selec-
tion decision (the ultimate goal)?

Looking back, my approach was to use a work breakdown structure to orga-
nize the details. There were about a dozen first level subjects, each with sev-
eral sub-items, making for about 200 total characteristics and features to