Howdy all,

For those who asked, the home PC is coming along ok, biggest loss was the e-mail files and address book. Sigh.... %$#@ virus lost us the hard drive... every bit.

Now, trains.

Following another thread which is mostly rants from several corners, I see the subject of rail transport being bandied back and forth.

Lets stipulate that maybe a certain reduced level of traffic can be sustained without computer switching. Not sure how, and I remain pessamistic, but lets just say it's so.

What I would like the big brains to discuss so I may follow in rapt attention is how failures in RAILINC and the railroads own systems for TRACKING rolling stock will play out. I recall some interesting times for an out west railroad last year/year before. Something about a merger that failed partially and 1000's of lost stock clogging rail yards.

I would LOVE to hear how this won't be a big problem, how it's already fixxed or something is in place to back up the bar codes and 'radio tag' readers.

Like Cory, I REALLY REALLY want to hear more good news. Come on folks, it's just a few months. some more good news would be apreciated.

-- Art Welling (artw@lancnews.infi.net), April 27, 1999

Answers

FYI, posted this awhile ago, but seems to be on topic:

Year 2000 Readiness Assessment January 1999

Year 2000 Readiness Assessment
January 1999

OVERVIEW: This summary assessment for January 1999 covers the eight U.S. Class 1 freight railroads remaining after the acquisition of Conrail this year. These railroads account for 91% of total U.S. freight railroad revenue, 89% of employees, and 71% of miles operated. Their operations span all states other than Vermont, New Hampshire, Maine, Alaska and Hawaii.

All segments of the rail industry are very much aware of the critical importance of addressing the potential problems that could affect computer systems with the century change. Railroads and rail suppliers are actively engaged at every level in identifying and preventing these problems.

Our first priority is the safety of our employees, customers, and the public at large. The rail industrys Year 2000 efforts in safety-critical areas address mainframe computer systems, decision support systems, and a variety of components supplied by vendors, including embedded devices. Railroads have received many inquiries about signals and highway grade crossing devices and have good news to deliver in response to these inquiries. Research and testing experience by railroads and rail suppliers shows that the safety-critical aspects of signals and grade crossing devices do not employ date calculations. Because of this they are not subject to the sort of Year 2000 problems that affect some credit cards, telephone systems, and older mainframe computer programs.

We believe that the rail industrys approach will enable it to continue safe, customer-responsive, efficient rail operations before, during, and after the century change.

YEAR 2000 PROJECT ORGANIZATIONS: Each of these large railroads has been actively engaged in a Year 2000 readiness project for several years with defined milestones and accountability. The Chief Executives of each railroad receive regular status reports. Senior management sponsorship and involvement is typical, since electronic information systems play a key role in meeting customer requirements and productivity goals in large-scale railroading today.

YEAR 2000 PROJECT EXPENDITURES: These eight large railroads spent approximately $150 million on their Year 2000 Projects through December, 1998. They expect to spend approximately $225 million in all.

ASSESSMENT (those activities required to define the scope of the problem and set up the infrastructure necessary to solve it): All respondents except two report 100% completion of the assessment phase for mission-critical systems. One of the exceptions reported 96% in January with 100% expected shortly thereafter. The other exception is 100% complete with assessment of core information systems and electronic commerce systems, and is currently completing assessment for other areas.

RENOVATION (those activities required to change information processing systems, including external interfaces, and fix processes dependent on microcircuits): All respondents are currently 100% complete with mission-critical renovation or expect to be 100% complete no later than July. The January status for critical renovation ranges from 75% to 100% with a rough average of 90%.

VALIDATION (those activities required to test, verify, and validate renovated systems, including external interfaces, and processes dependent on microcircuits): The January status for critical system validation ranges from 50% to 100% with a rough average of 85%. All respondents expect to be 100% complete with validation by September, with all but two complete in July or before. (Some of the validation included is date-forwarded testing which will occur after the remediated systems are implemented into production status.)

IMPLEMENTATION (those activities required to return a modified system or renovated process to production): The January status for critical system implementation ranges from 75% to 100% with a rough average of 85%. All respondents except one expect to be 100% complete with implementation in July or before, with the exception 100% complete later in the third quarter.

INFORMATION FOR SPECIFIC RAIL EQUIPMENT:

a. Signaling systems: During widespread testing by both railroads and signal suppliers no century change problems have been discovered that will impact safety or the operation of signals. The event recorders on a few older signals will need to be re-set. Even if the required re-set were not accomplished as planned, it would not impact safety or operations.

b. Interlocking plants: Testing results have been similar to that for signals.

c. Dispatching office systems: Required software upgrades have already been applied or are planned for implementation no later than third quarter 1999 (mostly complete in first or second quarter).

d. Telecommunications systems, both fixed and mobile, internal and commercial: Any required software upgrades or hardware replacements have already been applied or are planned for implementation no later than third quarter 1999 (mostly complete in first or second quarter).

e. Grade crossing signals: The operational components of grade crossing signals have been tested and do not require remediation. Some event recorders will require resetting the date after 1/1/2000; even if the required re-set were not accomplished as planned, it would not impact safety or operations.

f. Tunnel ventilation fans: One railroad has indicated that some remediation is required. This will be completed in first quarter 1999.

g. Draw bridges: No century change implications.

h. Wayside failed-equipment detectors: The operational components have been tested and do not require remediation. Unless remediated, a few of the oldest hot box detectors will print the wrong year on the chart recorder tape, but this is not a safety issue.

i. Automatic equipment identification system readers: Microcomputer hardware and software is being upgraded no later than third quarter 1999 (mostly complete in first or second quarter).

j. Locomotive electronic controls and cab displays? No century change implications.

k. Locomotive event recorders: Some railroads have discovered that remediation is required for some units. Work is underway and is expected to be complete no later than third quarter 1999.

l. Computerized diagnostic tools in locomotives? No century change implications.

m. End-of-train transmitters and receivers? No century change implications. Typically, times are only stored for 8 hours before being over written.

n. Electronically-controlled pneumatic brake systems? No century change implications.

o. In-shop wheel, axle, and bearing inspection equipment and other computerized shop equipment: The operational components have been tested and do not require remediation. Some equipment that logs dates incorrectly on reports requires remediation.

p. Vehicle-borne inspection systems: Some PCs must be powered off on 1/1/2000, powered on, and the internal clocks reset to the proper date. Plans are completed to follow this process where necessary.

CONTINGENCY PLANS: As part of their efforts to address the Year 2000 challenge, these larger railroads are actively pursuing development of contingency plans covering internal problems that may arise as well as external failures that could impact operations.

Year 2000 contingency plans at these railroads are generally based on the foundation of business continuity and disaster recovery plans previously developed. The railroads are investigating the requirement for additional Year 2000 contingency planning through risk assessments in the specific areas with potential century change problems. Areas covered include:

• Provision for remedial action to protect critical facilities from disruption due to loss of power, heat, water, elevators, building access, and fuel shortages.
• Provision for protection and/or contingency plans for major operations infrastructure such as Telecommunications Systems, Dispatching Systems, Signal Systems, and Automatic Equipment Identification Systems.
• Provision for protection of operational supplies/materials based on vendor readiness and risk factor including equipment repair materials, emergency maintenance material, locomotive fuel, and locomotive repair materials.

Railroad contingency planning includes assignment of adequate staff for on-duty status so that any problems arising over the January 1, 2000, weekend can be addressed immediately.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

Art,

As long as you are issuing a summons to the big brains, I'd like to read their opinions on this:

Firms Dump Data To Avoid Y2K Problems http://www.currents.net/newsletter/click.phtml?ct=672

One quote from above article:

"Year 2000 online warehousing involves taking the historical data from the non-compliant mainframe, compressing it and archiving it on a PC server-based system, which is less costly on storage and maintenance.

The data is then kept online using complex data retrieval software, which means it can be retrieved and viewed instantly on any PC in the organization."

Question: An inexpensive Y2K solution for ALL mainframes?

I haven't the expertise to know.

:)

-- FM (vidprof@aol.com), April 27, 1999.

Hoffmeister,

That is indeed a very positive statement. Who issued it? I have looked at your link and still can't figure out the source. Is it from some 3rd party verification report? I think you can agree that Art's open invitation to discuss this is based on serious concerns. Even since the above report was issued (Jan?) Koskinen has made some references to the railroads in a less than positive way. Is there something else you have available that is not just self reported which can give us more positive information? Art did bring up a good point about the merger disorder problems, which caused some serious shortages of coal delivery to some untilities for quite a while, and wasn't even related to Y2k as far as I can tell. So the larger question remains, will Y2k disrupt the rail computer management systems, and if so, will this cause serious slowdowns of their freight movements? Hoff, what do you think?

-- Gordon (gpconnolly@aol.com), April 27, 1999.

Gordon, the report is from the US Department of Transportation Year 2000 web page.

-- Amused (err@hmm.hmm), April 27, 1999.

Sorry, un-framed the link to get to the page.

The DOT site is here.

While individual companies may use independant third party reviews, I seriously doubt any industry wide assessments will be auditted, the current exception being the NRC plan to audit all Nucleur plants.

Companies look at Y2k projects as internal efforts. And, unless you count audit reviews, I've never had a project subjected to a third party validation/verification.

Folks here tend to mistrust internal assessments, assuming corporations have an incentive to lie about their status. But I gotta tell you, companies have even more incentive to actually get the problem fixed, and stay in business. Especially upper management. I worked for a company in the mid to late 80's that sunk itself into extreme debt to avoid a takeover, all in the name of upper management keeping their jobs. They aren't just sitting around now, idly lying to the public, so that in another 8 months the business will tank.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

Some additional info:

The UP info was posted on the other thread. UP Project Status

Also found this on Norfolk Southern. Link

(snippage)

Operating Data and Accounting Systems

The Y2K problem has been divided into several stages: awareness, assessment, renovation, validation, implementation and contingency planning. What stage of the process have you reached:

1. Our project is broken into Mainframe, IT non-mainframe and enterprise components.
   1. IT Mainframe - All business critical applications have been inventoried, assessed, renovated, unit tested and placed back into production (implemented). System integration testing (validation) is the outstanding component.
   2. IT Non-Mainframe - All business-critical components have been inventoried and assessed. We are approximately 80% complete with renovation.
   3. Enterprise - All business critical components have been inventoried and assessed. Approximately 20% of those items are non-compliant. Of the non-compliant items, approximately 20% have been renovated.
   4. We are beginning the contingency planning phase

What percent of your operating data and accounting systems are currently in Cobol, machine language or other early-generation programming languages?

Approximately 80%

What percent of your systems mainframe and PC, LAN and WAN have been made Y2K compliant and certified?

Approximately 90% have been renovated. Validation will be achieved through testing.

When do you expect your systems to be completed and certified?

Goal for systems to be implemented is June 1, 1999

Do you have contingency plans in place in case you do not make the deadline or have inadvertently missed something, and what are they?

We are beginning to roll out our process to develop contingency plans in those areas that we have considered a high risk.

Have you had any Y2K related failures yet?

No

Are you aware that there are over 30 days of concern, not just Jan. 1, 2000?

Yes

Will you be able to distinguish between a Y2K malfunction and a cyber hacker attack?

Unknown

Will payroll be affected by the Y2K problem?

Not to the best of our knowledge

Control Systems

Have you investigated the imbedded chip problem, where real-time clock circuits imbedded in electronic hardware may cause a Y2K failure?

We have contacted software supply vendors to investigate and test the NS CADD and PCS centers and have verified with supply vendors operating hardware & embedded systems. Additional testing will be done after implementation of Y2K patches with interdepartmental interfaces.

Have you identified any Y2K problems concerning:

1. Signaling Systems - No
2. Interlocking Plants - No
3. Dispatching Office Systems - Yes, as noted above, contract vendors are developing system software patches to be implemented with operating software patches for Y2K fixes.
4. Telecommunications systems, both fixed and mobile, internal and commercial? - Yes, Suppliers are not Y2K compliant. The NS microwave is compliant. Other non-compliant components include some handheld radios and a network monitoring device which are being replaced.
5. Grade Crossing Signals - No, and grade crossing signal event recorders - No
6. Tunnel ventilation fans? - There are no tunnel ventilation fans on the NS line at this time.
7. Drawbridges - We have not identified any embedded chip problems with NS bridges. Generally, there are back-up generators and manual controls to allow operation in the event of power failure.
8. Wayside Failed Equipment Systems - No, vendor verified.
9. AEI System Readers - Communications equipment - Yes, AEI readers from the vendor SAIC are non-compliant. The vendor is to supply patch in April 99. We have approximately 20 of these readers, which is a minority of our total.

Rolling Stock

Have you identified any Y2K problems with:

1. Locomotive electronic controls and cab displays - No
2. Locomotive event recorders? Yes
3. Computerized diagnostic tools in locomotives - No
4. End-of-train transmitters and receivers - No dates used - times are only stored for 8 hours before being over written
5. Electronically controlled pneumatic brake system? - One NS train has this type of brakes and it is currently not being used.
6. In-shop wheel, axle and bearing inspection equipment and other - None
7. Vehicle-borne inspection systems? - No to the best of our knowledge

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

Hoff,

Is this the same DOT that has been given such poor grades by various congressional spokespeople for work being done on their own systems? I have a problem with people reporting on remediation within their own area when they are not even ready themselves. Also, regarding your comment about management getting on the stick to preserve their own jobs, I would say two things. (1) A lot of upper level management folks have been bailing out on their golden parachutes lately. (2) I have a personal friend who is in upper level management for a major canned food company (with all the many acquired companies as well) and he is the biggest pollyanna business guy I have ever personally met. He really thinks like Poole, that there is not big problem coming, because computers are not all that critical to them, and a basic windowing approach has solved all their own potential problems. For him, this is a non-issue, and "let's get on to the real problems of market share and aquisition of some more competitors!"

-- Gordon (gpconnolly@aol.com), April 27, 1999.

(1) A lot of upper level management folks have been bailing out on their golden parachutes lately.

Gordon,

One cannot just "bail out" on a golden parachute at their own choosing. The golden parachute clause in an executives contract is only triggered upon a significant change in ownership. Maybe you should follow your own advice and do better research. ;)

-- RMS (rms_200@hotmail.com), April 27, 1999.

gordon,

Invalid concern. The regulation arm can report quite effectively and accurately while the rest of the organization may be looking for the proverbial paddle. The regulation arm is fully capable of giving a valid assessment in this case. After all, it IS what they do.

Chuck

-- chuck, a Night Driver (rienzoo@en.com), April 27, 1999.

Gordon, you'll have to enlighten me as to how the status of DOT's internal systems affects their ability to report on the industry assessments.

I see posted once in awhile a report of someone resigning, but certainly nothing that seems out of the ordinary.

As for clueless management, agreed that the Peter Principle is in full effect at the mid-level management. But most VP's I've dealt with were very sharp, and knew their sh*t. Granted, they may not understand IT completely, but they definitely know when they're being lied to.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

RMS and Hoff,

OK, perhaps I used the golden parachute phrase incorrectly. What I was referring to was a situation in which a business top management person invokes the right to early retirement, together with all the stock options and other perks that were written into their agreement.

As to the question of reliable information coming out of some agency that is not itself remediated, or even ready, I can only say that it seems to be a common sense approach to me. Look at all the misinformation coming from the FAA. Is the self reporting of railroad remediation work an exception to the continuous flood of "over confident" information coming from so many industries? Maybe you are right, and the railroads will be moving freight at the same brisk clip next year as they do right now. I certainly hope so. My opinions are my opinions, and perhaps you will agree that with so little 3rd party validation going on, there is plausible reason to doubt some of the statements being made. There is so much at stake here, don't you agree? The railroads will be critical to coal delivery to the power plants, as well as other daily consumer needs. Do I understand you to say that there is no evidence to suggest that there will be any meaningful problems in that area?

-- Gordon (gpconnolly@aol.com), April 27, 1999.

(Deep Breath)

Umm, and just what misinformation regarding the FAA has been issued by DOT?

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

Hoff,

So help me god I don't know why I get involved with a dedicated polly. I can't even use No Spam's excuse. Maybe you can tell us all why you get involved with the dedicated skeptics on this forum. BTW, did you read all the Matt Vaughn essays? I think you will find yourself described in there, I know *I* did. God Bless you and yours, if you believe in that sort of thing.

-- Gordon (gpconnolly@aol.com), April 27, 1999.

No, I haven't read the "smart college kid's" essays. Have seen his posts on c.s.y2k, and usually skip them now.

Why do I get involved? Deluded, really. I actually think the truth is out there, and that actual discussions of the issues tend to bring that truth closer to the light. Maybe I also think that there may be many lurkers stopping here, that tend to get a very one-sided presentation of the issues.

Of course, if you ask Ray, I'm some sort of government spy. Take your pick.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

Hoffy: RENOVATION ... or expect to be 100% complete no later than July. VALIDATION ...expect to be 100% complete with validation by September

IMPLEMENTATION respondents except one expect to be 100% complete with implementation in July or before

The problem is that frequently IT projects are 90% complete for, oh, years after the initial deadline as one milestone is slipped to another and another later date.

Too many expect tos, to much wishing really, really hard. Too much verbage hiding the facts. I'm buying more grain and canned food.

-- cory (kiyoinc@ibm.XOUT.net), April 27, 1999.

Cory,

What kind of corn do you recommend for home grinding into corn meal, if you know? I see on other posts that popcorn is not too good for this due to the hardness, yet others say it is fine. Oh, and just to stay on topic, do we need the railroads running their regular schedules to get bulk corn next year? :-)

-- Gordon (gpconnolly@aol.com), April 27, 1999.

I would be interested in the opinion of Hoff, CET, RMS, and all the other big brains around the forum on the impact of the Chernobyl virus, being discussed on another thread. It seems that about a million computers overseas had their hard drives wiped clean yesterday by the itty bitty bug that only affects PCs, and of those, only those with Windows 3.1/95/98. The economic impact is still being assessed, but the term disaster is being used in many of the affected countries.

Just another example of how easily computing threats can be underestimated by the overly optimistic and technically illiterate.

-- a (a@a.a), April 27, 1999.

Well, Cory, since they aren't done yet, they would have to use those words, wouldn't they?

Bon Apetit!

-- Hoffmeister (hoff_meister@my-dejanews.com), April 27, 1999.

To Hoffy: The problem is that IT projects that are due in, for example, March 1995, will frequently slip to July 1998. How often does a complex project come in on time? In the grand scheme of things, we are down to the wire and they're still not done.

About corn and other grains, I don't know. I've been buying small quantities of grain at a local natural food/health food store, paying about fifty cents a pound. This is just to experiment with. I keep planning on hitting a farm/feed store but, well, that project is slipping too.

I can tell you that hand grinding grain is much more work than opening a bag of Gold Medal. It was fun the first few times but I'd need a cheering section or a couple helpers to make this a regular thing.

If you had kids, you might make it a contest.

-- cory (kiyoinc@ibm.XOUT.net), April 28, 1999.

Hoff,

You seem to always miss the main point of what people are trying to say. Cory is saying that most projects of any complexity come in late. I second that opinion. I have over 35 years of project management experience. I have planned and scheduled thousands of projects. Do you know how many of the projects (of any complexity) met their original schedule date? None, zippo.

Y2K is not just one project but literally millions of projects. Some are relatively simple to remediate, some are more complex. However, it is not really a question of fixing the problem. The code is broken but it can be fixed. The problem, now get this Hoff: the problem is not all of the projects will be fixed in time. What are the consequences? Who knows for sure, we can only guess.

-- Watcher5 (anon@anon.com), April 28, 1999.

YUP! If I'm going to hand grind grain on a regular basis,I'll either figure out a Rube Goldberg linkage using a bike, or have to tripple the stock of Ibuprofen for my shoulders (legacy of being a street paramedic).

Chuck, d n d

-- chuck, a Night Driver (rienzoo@en.com), April 28, 1999.

Obviously, there are a myriad reasons for a project being late.

But, at least from my experience, the reasons for a project being substantially late, ( > 6 months ), fall into two categories:

1) Invalid/Incomplete Business Requirements. The requirements created as the basis for development assume business process models, which can be wrong or incomplete. If these errors are uncovered post-development, they can lead to significant re-work, and can add large amounts of time.

2) Technical problems. Usually sizing of the systems and network. Saw one project get into integration testing, where the nightly batch was finally run end-to-end. The required batch window turned out to be something over 36 hours (per night). After the sys programmers got done with their tweaking and tuning, got it down to 22 hours. Left the company before it was completely resolved, but I believe they ended up having to scrap the DB2 version of the software for IMS.

In any case, neither of the above really apply to remediation projects. You have a functioning system, that at least nominally meets the business requirements. You aren't changing the business process. And while they may be late, the causes for them being substantially late are greatly reduced.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 28, 1999.

Hoff you are a stupid ass. I could fill this forum with technical problems that have resulted from our remediation, most of which have nothing whatsoever to do with the actual date fields themselves.

Are you really a software guy or are you just pulling our leg?

-- a (a@a.a), April 28, 1999.

I'm sure you've seen many problems. Sure also that you've always seen problems, with any software system. Yet to see one that didn't have problems. Guess that's the reason you have a job, eh?

Like I said, I could list quite a few reasons for a project being late. That's not the point. The point is what types of problems can cause a project to slip substantially, for example from a June deadline to missing Y2k completely.

Nobody said there wouldn't be problems, least of all me. My guess is some businesses may fail. My point is that those that do fail, will fail because of bad business decisions, in this case not addressing Y2k. Bad business decisions are nothing new, and neither are business failures.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 28, 1999.

Forget trying to prove it one way or the other on any specific effort succeeding or failing. The real issue is over all risk and avoiding same. The metrics (and experince of the grey beards) says there are ALOT which will not make it, will screw it up, will die trying.

"Show me the beef!" (my motto)

Pull out what you've got and wait. We will see what will and will not work. Why be exposed to a gigantic roulette wheel that can crush you and ruin your life in seconds? When things settle out then you can get back in knowing that the rock will not fall on you and what has it cost you anyway? Being different then all your buddies? Life can be tough sometimes.

Will the Rails be ready? Who knows! What is the probability they will not be ready .. to high for me. Buy your insurance plan now. Its called self insurance and though it may cost you a few bucks you will be able to call in the premium at any time. A sweet deal indeed.

-- David (C.D@I.N), April 28, 1999.

Amazing to hear Watcher5 say he has planned and scheduled 'thousands of projects', and his plan missed his schedule *every time*. And he still has a job!

I begin to get a better appreciation for what we're up against.

-- Flint (flintc@mindspring.com), April 28, 1999.

Awww, geez, Flint!

I mean, here I'm showing such restraint, letting that post slide, and you just gotta jump in and ruin it all.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 28, 1999.

Flint,

Please let me clarify a point. I did say that I have planned and scheduled "thousands" of projects during my career in project management. I also said that none of these projects (of any complexity) met the origibal schedule date. It is obvious that you don'nt have any in-depth experience in project management. So let me explain a little.

A planner is not a King. A planner is not all knowing. A planner is usually a member of a project team that includes a project manager and repsentatives from functional departments such as engineering, procurement etc. A planner develops a plan and schedule based on input from other team members and scope of work documents.

There are many reasons most schedules don'nt meet their original schedule completion dates. Some of them are: scope of work not clearly defined, budget constraints, weak project organizations, weak project managers, lack of upper management support, unrealistic activty durations, inexperienced personnell, shortage of personnell, weather conditions, political climate. I could go on and on. But I think you get my drift.

During my career, I've worked in some exceptional organizations and some pretty bad ones, the good, the bad, and the ugly. The point I would like to make is even in the best organizations, they usually did'nt meet the original schedule completion dates. Please note that I'm talking about the original schedule completion dates. As the scope of work was better defined the schedules were usually met.

The point I was trying to make is that complex projects usually don'nt meet thier original completion date. In my experience this is a fact. Is it something to get upset about? I don'nt think so, it is just the nature of things and should be planned for. What does this mean in the terms of the real world. To me it means that Y2K remediation should have started many years ago for most large organizations. Since most schedules do slip, this tells me that the organizations that started early, such as the Social Security Administration, will be OK, but those that started late won'nt make it.

For a large enterprize organization, Y2K is a planner's worst nightmare. To ensure work is accomplished, each detail activity must be planned and scheduled. This is almost impossible to accopmlish since you need a multi-tiered schedule that covers your companies suppliers, their suppliers, their suppliers, suppliers, and on and on and on. To ensure the schedule is met, periodic progress reports are required. This means that you need status from all of the elements in the multi-tiered schedule. Let's define supplier's as anyone external to the enterprize. For Y2K these will probably include, vendors, sub-contractors, utilities, customers and clients. In the real world it would take an army of planner's to just define and schedule these interfaces, so it just aint gonna happen.

So what choices does an organization have when they set-up their project plan? Very few, they must hold their first tier interfaces accountable and set-up a reporting system. They must trust that the people reporting to them are telling the truth. And in turn, the people reporting to the reporters, etc. etc.

So what does all of the above mean? What it means to me is that there is a break-down in planning, scheduling, and reporting in large enterprize companies. Now couple with with the fact that a lot of small and medium sized companies have no written plan and you can see my concern. A large percentage of Y2K are not being planned and scheduled.

-- Watcher5 (anon@anon.com), April 29, 1999.

Watcher, you make some good points.

Project scheduling is in essence a balancing act. Typically, not enough time is allowed for a preliminary detailed analysis. Which is why the available metrics, and the use of function points, while helpful, don't allow a complete view when the plan is first developed.

I usually make at least 2 passes at a plan, after the tasks and dependancies are defined. The first pass is made using actual estimates for completing the work, which in essence provides a "best case" view, and which also is totally unrealistic. Unforeseen delays always occur. I then typically add some percentage, usually around .25, to the major level tasks, to get a somewhat realistic view. The balancing act comes because, like spending/income, work usually expands to fill the time allotted.

Over-staffing a project to meet a deadline can help, but obviously does not reduce the time linearly. Task dependancies cannot be changed by adding more people.

But one of the points I made on another thread is important. Many companies set early deadlines, like Dec 31, 1998, and then attempted to staff/schedule to meet these. While many may have missed, it did allow a substantial portion of the work to be completed. One company I worked for called this method "extraordinary goals"; in essence, setting unrealistic deadlines to encourage people to come up with "out of the box" solutions in order to meet the deadlines.

I think you may also be putting too much emphasis on external interfaces, at least from the work required standpoint. I've seen very few instances where external interfaces were changed due to Y2k. For the vast majority, windowing dates works just fine, even if you have used date expansion internally. For the actual interface, the end result is in essence "fix in place"; and while testing still is required, it makes that testing less of a dependancy to your internal project. From a supply-chain point of view, you're still going to be relying on your supplier's statements.

-- Hoffmeister (hoff_meister@my-dejanews.com), April 29, 1999.