HP3000-L Archives

January 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Tue, 25 Jan 2000 00:36:54 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (53 lines)
David Gale wrote:
>
> I think Richard raises a good point. The project is co-founded from
> the beginning. A marriage of disciplines, both that of your business
> department, and that of the IS department.
>
> I have seen many projects 'managed' by managing the manager. It
> takes the excellent communications skills that Richard suggests. The
> point is, who takes ownership of the project?

This is all too true.  Third-party packages on a grand scale (ERP, Baan,
Peoplesoft, Banner, etc) are most often marketed to non-tech
administrators.  The vision is that you buy the software off the
shelf, they provide maintenance, you can relocate / reassign / outsource
your IT infrastructure.  Save big bucks.

They don't mention the administrative overhead, ignore the probable
change of platform/DBMS/development tools/utilities, evade the issues
which are unique to your business policies that they likely don't
support, and other issues.

IS/IT/whatever technical people need to be involved to point out issues
that may affect your specific infrastructure.  Network demands,
client platform and minimum requirements, and multiple points of failure
in a multi-tiered client/server environment need to be addressed.
Typical management has an ostrich mentality to this, they don't know and
don't want to know, so they stick their heads in the sand.  If the
project stumbles, in the worst-case scenario the finger is pointed at
IS/IT incompetence, or unco-operation, or simple resistance to change.
This can bleed down to the functional areas as
well.

A brand new implementation with no precedent - sure, you have no metric
to measure against and blindly follow the vendor like so many lemmings.
But replacing an existing system has to have proven advantages that make
business sense.  A pretty GUI is worthless if it is unreliable,
bug-ridden, inefficient, or doesn't meet your business
needs.  Moving to Unix/NT makes no sense for the same reasons plus
the additional system administration and software maintenance often
required by such systems.

In the "old days" IS/IT did tend to dictate business practices based on
what they could produce, which admittedly had it's faults.  But
currently we face a 180 degree shift where non-technical management
is dictating what IS/IT should do.  Neither paradigm works.

Hopefully both sides will see the light and we can come up with a
solution that satisfies the real business needs for the end-users while
remaining a solid, reliable platform that IS/IT can support
and enhance to benefit the enterprise.

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2