Boot Hill Web Site

Gentle people:

Many months ago I came across a web site that was a "Boot Hill" site
listing all the failed "See Bull" projects. I think it also listed
other CRM and such projects that had failed. Some of the ones that had
failed also had listed the cost of the project in $$$ and people.

I also knew about a site that listed the actual results of C Bull
implementations from the ones posted on the See Bull web site as
reference accounts.

If any one knows of such a site that still exists, I have a new
candidate for them.

It seems that a certain privately held company had a CEO that decided
that the company must modernize. The mainframe is just not going to cut
it, and so they must move off to some "Best Practices" system. So
rather than making the C Bull vendor prove that they could handle what
the CEO envisioned, the CEO allowed Infernally Bad Management and See
Bull to put together specs and then build this new state of the art
system.

Did I mention that they laid off a lot of people? Did I mention that
they rebuilt their computer room twice to handle all the Regatas that
would take the place of that one mainframe?

Well, the CEO finally had his new clothes. In order to get things to
come close to looking like the mainframe system was slower than the
Siebel system, the CICS group was told to insert an "EXEC CICS WAIT"
for 1 minute any time they accessed a certain file (the main file for
the whole process). The mainframe still left the C Bull system in the
dust.

The Board finally handed the CEO his hat, after they had tried three
different groups (including offshoring to India) in an attempt to get
this project done.

Now after spending at least US$20M on HARDWARE, the mainframe is still
the only system that can do the job and be recovered in less than 12
hours at the DR Site. Did I mention RIFs? Did I mention IT
housecleaning that finally reached to the Executive VP levels?

What I would like to know is, why did it take the BOE three years to
offshore the CEO position?

At any rate, I want to put this unnamed company that is found in
Columbus OH in the list of companies that has been unable to implement
See Bull, and may not be able to recover and have to be disolved.

Did I mention that they migrated from VSE to Z/OS and fixed all kinds
of problems in their COBOL code so that the mainframe became very
boring because the frequency of crashes discussed in the morning status
meetings was eclipsed by every other platform?

Later,
Steve.T

Have a great time, and give us all the details. Be sure and post a
notification/pointer when your finished, so we can read it.

http://www.actscorp.com/reboothill.htm

Thanks,

Gary Walker





"steve.t" <sthompson@ix.netcom.com> wrote in message
news:1106699786.817548.115090@c13g2000cwb.googlegroups.com...
> Gentle people:
>
> Many months ago I came across a web site that was a "Boot Hill" site
> listing all the failed "See Bull" projects. I think it also listed
> other CRM and such projects that had failed. Some of the ones that had
> failed also had listed the cost of the project in $$$ and people.
>
> I also knew about a site that listed the actual results of C Bull
> implementations from the ones posted on the See Bull web site as
> reference accounts.
>
> If any one knows of such a site that still exists, I have a new
> candidate for them.
>
> It seems that a certain privately held company had a CEO that decided
> that the company must modernize. The mainframe is just not going to cut
> it, and so they must move off to some "Best Practices" system. So
> rather than making the C Bull vendor prove that they could handle what
> the CEO envisioned, the CEO allowed Infernally Bad Management and See
> Bull to put together specs and then build this new state of the art
> system.
>
> Did I mention that they laid off a lot of people? Did I mention that
> they rebuilt their computer room twice to handle all the Regatas that
> would take the place of that one mainframe?
>
> Well, the CEO finally had his new clothes. In order to get things to
> come close to looking like the mainframe system was slower than the
> Siebel system, the CICS group was told to insert an "EXEC CICS WAIT"
> for 1 minute any time they accessed a certain file (the main file for
> the whole process). The mainframe still left the C Bull system in the
> dust.
>
> The Board finally handed the CEO his hat, after they had tried three
> different groups (including offshoring to India) in an attempt to get
> this project done.
>
> Now after spending at least US$20M on HARDWARE, the mainframe is still
> the only system that can do the job and be recovered in less than 12
> hours at the DR Site. Did I mention RIFs? Did I mention IT
> housecleaning that finally reached to the Executive VP levels?
>
> What I would like to know is, why did it take the BOE three years to
> offshore the CEO position?
>
> At any rate, I want to put this unnamed company that is found in
> Columbus OH in the list of companies that has been unable to implement
> See Bull, and may not be able to recover and have to be disolved.
>
> Did I mention that they migrated from VSE to Z/OS and fixed all kinds
> of problems in their COBOL code so that the mainframe became very
> boring because the frequency of crashes discussed in the morning status
> meetings was eclipsed by every other platform?
>
> Later,
> Steve.T
>

I think I did already. What I originally posted will be much more than
what will get posted on the ReBoot Hill site.

It is interesting that I got accused of being a mainframe bigot when I
got the numbers and showed them that no matter what they did, they
would fail.

Let me just cut to the chase here. In too many instances, upper
management of a company wants to be doing "best practices". They refuse
to listen to any people that know architecture. The I/O (bandwidth)
required by the non-mainframe systems to implement CRM (and the like)
is incredible. Had the systems been designed from day one with that new
language on that new platform, they might have had a chance. But the
problem is, they are trying to re-design a system and compete against
the most efficient I/O design (memory centric v. bus centric).

And so, upper management may declare the new system to be a success
when the users are astonished at how much functionality they have lost,
call center managers are appaulled at how many more seats they have to
have to process the call volumes (and not have an increase in dropped
calls).

Or, it becomes so obvious that the new system is being crushed under
its own weight that they have to abandon it.

And if any of you think I'm kidding, start looking at what a brand new
_____ (open systems machine, CPU, RAID, etc.) sells for, and then what
it is worth on the used market 60 days later. There is a reason why the
used market is glutted with RAID devices and "Open Systems" boxes.

But everyone will tell you that COBOL is dead or will be shortly
(colleges are pushing the new fad languages).

Maybe that's why I do software development with COBOL because with a
few changes it runs across so many platforms. And it is so easy for the
newbies to learn!

Later,
Steve.T

What can I say, I agree.....

I've always found it very interesting, that even with semi-like arch-
itectures, these conversions can be very troublesome. In my exp-
eriences, it's always amazed me how the functionality of the orig-
inal system(s) will seem to disappear as the bleeding begins.

Eventually, one is only "very" lucky to achieve the original func-
tionality on the newer platform, as overlooked issues are cast
aside to adhere to an overly optimistic schedule.

Often, in addition to pure conversions costs, maintenance and
enhancement costs rise to overcome these discarded options.
Users become disappointed/unruly, sometimes original functions
are discovered missing, that were even unknown. The oversight
and be endless.

It's usually about this time, that the architects of this debacle
begin to gain scrutiny, followed by a stream of post-conversion
meetings. If the result(s) cannot be corrected quickly, this is
usually followed by a trip out the door. This appears to be the
case with your experience. The lies start rolling, and CYA tactics
abound. These conditions are the meat from which cliché's are
formed.

Sound familiar?

But, it can be done, with detailed planning, and someone that
is willing/able to deliver the "not so rosy" forecast. Unfortunately,
I've not seen anyone yet of this caliber.

Have no fear, yours will not be the last experience of this nature.

Thanks,

Gary Walker



"steve.t" <sthompson@ix.netcom.com> wrote in message
news:1106760223.795942.232500@c13g2000cwb.googlegroups.com...
> I think I did already. What I originally posted will be much more than
> what will get posted on the ReBoot Hill site.
>
> It is interesting that I got accused of being a mainframe bigot when I
> got the numbers and showed them that no matter what they did, they
> would fail.
>
> Let me just cut to the chase here. In too many instances, upper
> management of a company wants to be doing "best practices". They refuse
> to listen to any people that know architecture. The I/O (bandwidth)
> required by the non-mainframe systems to implement CRM (and the like)
> is incredible. Had the systems been designed from day one with that new
> language on that new platform, they might have had a chance. But the
> problem is, they are trying to re-design a system and compete against
> the most efficient I/O design (memory centric v. bus centric).
>
> And so, upper management may declare the new system to be a success
> when the users are astonished at how much functionality they have lost,
> call center managers are appaulled at how many more seats they have to
> have to process the call volumes (and not have an increase in dropped
> calls).
>
> Or, it becomes so obvious that the new system is being crushed under
> its own weight that they have to abandon it.
>
> And if any of you think I'm kidding, start looking at what a brand new
> _____ (open systems machine, CPU, RAID, etc.) sells for, and then what
> it is worth on the used market 60 days later. There is a reason why the
> used market is glutted with RAID devices and "Open Systems" boxes.
>
> But everyone will tell you that COBOL is dead or will be shortly
> (colleges are pushing the new fad languages).
>
> Maybe that's why I do software development with COBOL because with a
> few changes it runs across so many platforms. And it is so easy for the
> newbies to learn!
>
> Later,
> Steve.T
>