Might I ask who's pocket the $50K is coming from?

-----Original Message-----
From: Al [mailto:[log in to unmask]]
Sent: Tuesday, January 25, 2000 1:36 PM
To: [log in to unmask]
Subject: Re: IT Project Implementation


Thanks Everyone for their response. The problem we in the IS are facing is
that the functional department has selected a package but not ready to place
the order yet. The third party vendor has been asked to scope the project
and submit an implementation plan and the final documentation to us as to
what the deliverables will be; i.e. a Project Spec. For this we are paying
them for 5-days consultancy fees. But they have insisted to out user
department manager that before they can scope the project we must purchase
all hardware and databases and set the system up so that they can use their
generic software to produce the project spec. This is going to cost us $50K
to set up before we have put the order to purchase the system. The business
manager agrees with the software supplier but our FD has asked us if this
makes sense and we have said NO. This has put us, the IS, in a situation
where our experience tells us this doesn't make sense but the user
department argues otherwise.
Al



Jeff Kell <[log in to unmask]> wrote in message
news:F4B1826B1A21D211AEC5006008207AF4043774EE@dogbert.csillc.com...
> 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]>
>