Paul, Re" "I'm still trying to get better information on the REAL CAUSE of the delay - so at this
point in time, I have no concrete reason for the delay."
First, thanks for researching the real cause of the Merced delay. I'd really like to hear what you find out.
When it first surfaced, the articles were saying Intel was having "technical" problems. Later it was manufacturing problems. When Barrett finally was heard from, he said it could be best described as a program management problem. He didn't allude to any architectural, technical or manufacturing problems.
I am familiar with projects like Merced. In such projects, there are hundreds, maybe thousands of sub-projects to manage, and tens, maybe hundreds of thousands of tasks below those sub-projects to execute. Interdependencies are everywhere, such that if one task slips, it can bump out hundreds of others. People from many different types of engineering all have to get their stuff done, and several other groups may need to have to get their stuff done first, before you can get your stuff done...architecture, hardware, microcode, software, diagnostics, process,...you know. Microsoft must love it, as their Microsoft Project planning tool is widely used by Intel. There must be a thousand copies at Santa Clara (if that's Merced design center) Intel alone. I don't know who's seen a Microsoft Project (or any other planning tool) project plan for a project like this. Bottom line is that if you could get it all on one plan, it would look like a three dimensional, rotating, pulsating spider web from Hell. Sorry for the cartoon depiction.
Anyway, you may find out that Intel just did a major re-examination of the overall plan, and found that interdependencies delays just blew the late 1999 date out of the water. Maybe not, again, thanks for looking further.
In my experience, projects of this magnitude almost always do slip a couple of quarters when they are supposed to be 18 to 24 months from completion. Something about 18 to 24 months...upper management says 'OK, where are we really at on this project.' Everyone scurries off, does their sub-project plans, they all get rolled up, and, surprise, we're late by six months.
A comment on the complexity of Merced, and the amount of work needed to be done to complete it: in the mainframe world nowadays, companies change only one major aspect in a new machine design at a time. It goes new architecture, same technology; same architecture, new technology, new arch., same tech., etc. Of course, the software is staying essentially the same but with new firmware and microcode. Intel, with Merced, is changing the three major things that can be changed in a CPU (at least) here: architecture, technology and software (MSFT, SCO, etc.).
Not to say that the complexity of Merced, and the fact that everything that could have changed (except Silicon) is changing, are excuses, but they are reasons that I understand. I hope you find out that the major problem is as Craig says: program management. If not, let us know what the prognosis may be.
Thanks Paul,
Tony
|
