I'm away from the computer for a few days and what a wonderful mix of posts and comments I find upon my return! There were a lot of thoughts running through my head after a quick perusal of Rick's assessment of the most recent NERC report, and Tom Benjamin's straightforward posts are always a pleasure to read. [I do a lot of affirmative head nodding with nearly every sentence I read of yours, Tom.]

I'm a little frustrated at the moment because my time is limited today, likely will be through the weekend, too, and there are lots of comments I'd like to make. There's one thing which was foremost in my mind after my catch-up reading, however, so that's what I'll go with now -- the issue of LYING.

I'll bet just seeing the word in caps gave you a tiny little cringe inside. Most everyone swings out around the issue; there are discrepancies, padding of the truth, good intentioned fudging, upward chain distortion of facts and, of course, different definitions -- but never _lying_ about issues. Confrontations about lying have tended to be avoided in polite society for well over a century. [ Taking a wide stance, pushing the coat back and patting the holster, "Them thar's fightin' words, pardner." ]

While this has, and does, help keep people from getting bullet holes shot in them or teeth loosened in a fist fight, it's also enabled society to fall into a courteous trap of indirection. Nowadays there are lies..and not-really-lies.

"I promise to tell the truth, the whole truth, and nothing but the truth.." That's the court ritual anybody who watches television has heard many times. Ever ask yourself why our legal system determined that just a promise to "tell the truth" was not enough?

It's because there are lies of commission ("tell the truth"), lies of omission ("the whole truth"), and lies mixed in with truth ("nothing but the truth"). Unlike the legal parameters, most people only think of lying in the first commission mode - a straight out bald faced deliberate non-truth. We don't like to think about the other kinds, because we all practice those types of lying ALL the time.

"Have you been eating the frosting on this cake, Sarah?"

Hanging her head, "Grandma, I....I....only did it a LITTLE." [finger holes all over the cake]

And about those tax returns, everybody.... or those resumes...or the expense accounts... "But it was only a little"..."Everybody does it"....."It wasn't much at all,"..."It was technically the truth...."

Now let's get to Y2K. In the middle of last year, the IT manager of a small/medium business, whom I know well, called and said he'd gotten "these letters" from people wanting to know what the company's Y2K status was. The Year 2000 problem had just been entering his company's awareness and he complained to me, "What the hell am I supposed to do about these things?" It was a rhetorical question, because he had already decided. He sent them back a "we're working on it" and "we'll be ready in time" letter. Then he actually started working on it a few weeks later, _hoping_ he'd be ready in time. And he's worked his butt off, but is stalled in complications from the first integrated tests he's done.

Did he lie? YES. Hopeful thinking, no matter how good the intentions for the future, does not equate with as-of-now truth.

My local bank announced they were "Y2K Ready" at the end of June. The tellers all had "Ready" buttons on, etc. This week there's an announcement that the first of the bank's three ATM machines will be out of service on such and such days because they are being replaced with the most brand new up-to-date machines. [Even though the "old" machines were only put in about three to four years ago.] The bank was ready because...well, this was _scheduled_, even if it wasn't exactly implemented yet....

Then there is the lying by definition. We've all had lots of laughs over the "It depends on what is, is, " line used by our President. As funny and ridiculous as it appears to most people, it's far from an unusual position nowadays. That's exactly why a business of any size has a lawyer or lawyers on staff. Wording is everything when it comes to a determination of lying. If a word definition exists whereby a statement may be later defended as truthful, even though the overall falsehood stands out clearly, well....then it's not _really_ a lie.

Months ago, I sent an e-mail to the appropriate person listed on the NERC website as the one to address questions to about the NERC survey forms. I politely asked, concerning the "Rmd/Tst" category on the survey, if a component was assessment-tested and then fixed but had not undergone any validation or integration testing, did it qualify to be counted in the "Rmd/Tst" category, or was the testing part for post-remediation testing only? I never did get an answer to my e-mail. I did get an answer from NERC in a roundabout way, however. In the April report to the DOE I came across:

"NERC has adopted the use of three phases: "Inventory," "Assessment," and "Remediation and Testing". NERC has deliberately avoided placing a strict definition on these three phases, so as to prevent conflicts with previously existing internal project definitions."

So the definitions of what could be reported in the NERC survey categorys was left up to each individual utility.

How about the "whole truth"? There are a lot of SEC filings in which a company states they began their Y2K project in 1997. Sounds good, gives them three years to get ready, right? If you do some research, you can often discover that the company's first meeting to begin to organize a Y2K project occurred on December 15th, 1997, or a similar end of the year date, and the formal project didn't actually get under way until well into 1998. We say "technically" they didn't lie -- but they didn't tell the whole truth either.

If you're still hanging in there with me, now think about PEOPLE. Humanity. Then you might understand why I can affirm my complete conviction that there is a percentage of people involved in Y2K work and reporting who have flat out lied -- by commission. There is a much bigger percentage of people who have lied by omission (not told the whole truth) and by mixing lies with some truth (indirection).

From this Grandma's perspective, there is undoubtedly a LOT of lying going on in the Y2K arena. Ever go apartment or house hunting? The ads sound so great, until you see the place for yourself. The idea that Y2K has somehow become disassociated from human nature is balderdash. Lying is an endemic part of life. Society is now so immersed in "not exactly the truth" that we often no longer even equate it with lies. If you don't recognize this, I think you're either naive and haven't lived long enough, or you're an incurable romantic. The predilictions of human nature should be factored into _every_ Y2K status report you read.

No niceties here, no beating around the bush. Lies are lies. The Y2K issue is frought with them. Think I'm being too hardnosed? "Humph" So shoot me. Better yet, go try to explain why lies aren't really lies to your kids.

-- Anonymous, August 13, 1999

Answers

Bonnie,

Excellent essay, as usual. however, this time you have touched on a subject dear to my heart, lying and schedule status reports. As a retired Project Planner with over 35 years of project management experience I can attest to the fact that many, many, games are played with schedule status reports.

A favorite one is blame someone else, like I never said that activity was complete, the planner must of mis-understood me. Or there is the game of not using expected activity completion dates, but rather to show % complete and let the computer based scheduling software program calculate an expected completion date. That way one can always say " I never said that activity would complete two weeks from now, all I said was that it was 85% complete." Or the more subtle ploy, asking the planner what his best guess is, thereby shirkling any responsibility for the schedule. I can'nt tell you how many times someone who is responsible for an activity has told me that he really did'nt know the schedule status and for me to just use my own best estimate.

Nobody likes thier work to be scheduled. They are being pinned-down to make a commitment regarding thier work activities. Most people find this to be very uncomformtable. Those that are new to this effort are really astounded after you have wrung a schedule out of them that now you want schedule status??? You never told me that!! You mean you want me to tell you if I'm going to finish that activity on time?

So in time, a good planner learns how to get schedule status with a minimum amount of game playing. I learned to print out a schedule with the past due and upcoming activities circled. I then would ask the responsible party (in writing) to denote actual schedule completion dates by noting the date and a (a) next to it, and to reflect expected completion dates for those activities not yet started or complete. I expressly asked them not to use per cent complete in lieu of expected completion dates. I then asked them to sign and date the status report. I can'nt begin to tell you the arm wringing I usually had to employ to get this.

So how does all of this play into lying and Y2K? I think from a project managment viewpoint and human nature nothing has really changed. I'm worried.

-- Anonymous, August 13, 1999

As usual, all your facts and figures are well documented. But on the issue of lying,or various shades of the truth, I think we've all seen ample examples of it. So, Bonnie, to use an old saying "you're preaching to the choir" :)

-- Anonymous, August 13, 1999

Crossposted to TB2000

Thanks, Bonnie.

Critt

-- Anonymous, August 13, 1999

Interesting post Bonnie, but I read it twice, and saw no evidence presented of a power utility lying about y2k readiness. I did see "facts" but no "figures", about your bank and that IT manager friend of yours, lol, but how 'bout 'lectricity?

My own opinion is this - I have no doubt that there are some companies who have "stretched" to declare Y2k readiness, even in the utility industry. But I certainly would say XXX LIED unless I had some damn good facts. And in the context of WILL WE HAVE POWER, this looks like a whiff of smoke...

Regards,

-- Anonymous, August 14, 1999

People like myself, who started their careers in a field such as construction engineering, but who eventually made a career change into software development, will tell you that it is extremely difficult to accurately estimate the length of time it will take to complete a large, complex software project. Or even a medium-size software project.

Even if the project planners have been diligent about getting the proper data from the programming staff, even if the programming staff has been honest among themselves about how much work it will take to write and test a set of software modules, even if a tight design spec has previously been engineered for that software application, and even if the programming staff are experts in the languages they are using, one often finds that completion estimates for a particular task or a subsidiary milestone are off by 20%, 30%, 40% or more.

Why is that? Well the short answer is that software is different. There are any number of technical glitches and problems that can arise -- seemingly out of the blue -- while the code is being initially written and tested. That happens to the best of programmers, even under a well-disciplined software development approach. Often a particular module turns out to be more difficult to code than was originally believed, either because the code spec is asking for a piece of functionality that is not easily provided within a particular language; or because the programmers, in choosing a programming style and technique for a particular module, have gone down a dead-end technical path, and have to start over again with a fresh approach.

In estimating software projects, you have to take your best shot at estimating every low-level task, and then arbitrarily add in a cushion of 30%, 50%, or even 100% per task, based on the functionality being constructed and the technical development environment being employed, e.g. client server, mainframe host, etc.

As you can imagine, corporate managers don't want to hear that a particular low-level task contains 100% contingency; or that overall, a particular project has a 30% contingency built into it. Management has hired a professional staff to do this kind of work, and they expect that reliable task estimates with minimal contigency can be provided. In general, they do not buy the notion that software is different.

How do I handle this situation myself? When I plan a project, I do not discuss my task cushions with management, except to state that minimal and appropriate contingencies are present. I do this knowing that management's judgements about me and my character boil down to one thing: Are my software projects delivered on time and on budget, and with the functionality that was promised?

-- Anonymous, August 14, 1999

Scott,

I read your post with interest. I agree there are many types of projects that are extremely difficult to estmate with any degree of accuracy. The point I was trying to make was that a lot of folks did not want to be held accountable for their original task schedule duration. They would do anything possible to avoid telling management they were not going to meet a schedule completion date.

In my experience there is no perfect plan or schedule, there will always be room for improvement. However, this does not excuse individuals who practise lies and deceit when it comes to schedule status. In many instances this is the fault of management. If management yells and screams when a schedule date is missed, then it can hardly expect open and honest communication.

In any event, Scott, there is so much deceit and deception associated with project planning and scheduling that it causes me to really wonder about the state of readiness of Y2K as currently advertized.

-- Anonymous, August 14, 1999

Right on, Bonnie. This grandpa is right in step with you on this problem. I would just add that our society has abandoned absolute truth in preference for relative truth. Thus the position you take may be true for you but not for me.

NERC can broaden "Y2K compliance" to "Y2K ready" and make the relative truth cover a lot more ground. The target becomes so big that only a few power companies can't hit it. The media loves relative truth and so the fears of the public are placated and we have a mostly relaxed nation facing one of the costliest problems we have ever faced.

As for me and my house, we are prepared for three weeks interruption of our basic needs. And that is the absolute truth. We will use it for a blizzard or an ice storm if we don't need it for Y2K.

-- Anonymous, August 14, 1999

Scott and Bill,

I appreciate the difficulties in estimating completion dates for software. I agree that producing these systems is far less predictable than, say, building a bridge. But I think you are touching on the precise place where software engineers have to accept their share of the responsibility for the Y2k debacle.

I used to "buy" systems. I was in middle management of a large organization during a period of enormous technological change. When I say I bought a system, my unit always paid for the new system from the people budget. At first, I figured this was okay and happily re- adjusted my budgets and the way of doing business.

I quickly learned however that the systems were *always* delivered with less functionality than was promised, *always* cost more than the "budget", and *always* were delivered late.

After about the third go round, I used to start screaming about it. I'd look the systems guy right in the face and say, "Look at the track record! Eventually I love the system but let's put some realistic goals in this project. If we are going to lose functionality let's lose it right now so I know what I am going to get. I'm going to have to start paying for this system next year, and it will not be working properly until the year after. Let's set a realistic deadline, and let's meet it."

"No, no," the systems guy would say. "We just had some unexpected problems on the last project. The system is great now, isn't it? This time will be different. If we have forgotten a function you want, we'll add it! This one is a piece of cake."

To me being a professional means you promise only what you can deliver, and you deliver on those promises. The industry still cares too much about what neat tricks they can make computers do. They've got to get more realistic about things like deadlines and budgets.

Management is buying systems and making tradeoffs built around these estimates. A lot of bad projects get approved because the proposals are from Fantasy Island. The credibility of the profession suffers. It is one of the reasons IT has been left out of the loop. "Great at code, lousy at business."

I do not mean to hold programmers solely responsible for Y2k. Managers are also to blame, perhaps more so. In the end, we are all to blame for it because we all created this whacky values empty culture and society.

But the profession of programming has got to grow up. I think that is the Y2k lesson for the software industry.

Tom

-- Anonymous, August 14, 1999

Tom Benjamin: ".....software engineers have to accept their share of the responsibility for the Y2k debacle"

There can be no question of this. I will relate an incident that happened this spring, while I was visiting my parents at the house they have lived in for almost half a century. One of their neighbors, a grandmother herself, someone who has known me since I was four years old and who also knows that I'm no longer in construction engineering but in software development, asked me what my opinions were as to how such a thing as Y2K ever could have happened.

After talking with her at some length, I realized that she knew as much or more about the Y2K problem and why it happened as anyone who deals with the problem in a professional setting. She had no hesitation in pointing her finger at the programming profession: "You did it. You have no excuses. It was your obligation as a profession not to do something so obviously and so completely stupid."

She had no sympathy for my own situation, in that I was but eight years old when two-digit years became the norm for software programming, and only got into software after the recessions of the early 80's killed my opportunities in mining and energy construction. In her eyes, I am one of "them" now, one of the people that could very well be responsible for leaving her without power when it's -20 outside, without a pension check, maybe even without food.

Likewise both you and Bill Watt have every justification in being critical of the IT industry. My explanation of why software projects are nearly always mis-estimated was not intended to be an excuse for poor performance. (By "poor performance", I mean that the promised functionality was not delivered on time, on budget, or with the promised level of quality.) My explanation is intended to give some insight as to why software projects which seem to have a well defined and comphrehensive work breakdown structure often miss their targets for delivery date and cost, in spite of having a well-developed project plan.

Most certainly, there can be no excuse for any IT professional to act dishonestly in dealing with a customer. However, we know this problem is epidemic within the IT industry. I have personally witnessed several incidents where certain IT service bureaus -- who can only be described as technological snake oil salesmen -- have consciously and systematically lied to their customers about what they can deliver and when. On a few rare occasions, I have even seen this kind of thing happen within a corporate IT shop, through what can only be described as deliberate deception on the part of the IT staff. But within most corporate IT shops, incidents of deliberate deception are not that common. A psychology of incurable over-optimism is usually the culprit.

OK, how do the most blatant IT snake oil salesman get away with it, year after year? The single most important reason is that purchasers of IT services rarely take the time to make themselves knowledgeable customers for software development services. When a project is in trouble, the most likely missing element on the customer side is that customer management has not been proactive in dealing with problems as they emerge, and has not been watching carefully from Day One for evidence of poor performance on the part of their IT service provider.

To be this proactive requires that a customer have qualified people on his side who can examine, with a critical eye, everything that's being done. That is no less true for a customer whose IT services are being provided in-house. Rarely do I see customers taking the time to make themelves knowlegdable about the nuts and bolts of software development. That's why so many of them get taken to the cleaners.

-- Anonymous, August 15, 1999

Scott wrote:

When a project is in trouble, the most likely missing element on the customer side is that customer management has not been proactive in dealing with problems as they emerge, and has not been watching carefully from Day One for evidence of poor performance on the part of their IT service provider.

I agree. It became a vicious circle. Management did not understand the technology, and because they did not understand it, they abdicated their responsibility. The normal skepticism that senior management had when dealing with my performance and my problems as a non-IT manager was replaced by awe and wonder when dealing with IT.

They frequently did not even notice missing functionality as long as there were lots of neat tricks in the finished package.

Your comment about your elderly friend struck home with me. It was one of the first questions my mother-in-law asked me... "How could this happen?" I explained the history and how you could not really blame anyone in particular. If there was one factor more than any other it was timing.

We all think using two digits for a date and programmers are no different than anyone else. If we had invented computers in say, 1910, programmers could not have made the error. If we invented computers in 1990, programmers could not have made the error. It was bad luck as much as anything that computers came along mid-century.

Did this explanation fly with my mother-in-law? Not a chance. She used words like responsibility and obligation, too. "Not good enough," she said shaking her head, "They knew. They knew what would happen if it was not fixed. They depended on someone else to clean up their mess, a mess that was deliberately created. Not good enough."

We are going to change the way we look at management, at programmers, and at technology, no matter what happens.

Tom

-- Anonymous, August 15, 1999

Hi Tom, et. al.

Regarding software development, you make some good points. However, I must point out that software development is fundamentally different than almost all engineering tasks. My education and first jobs were civil/mechanical engineering jobs. For the last 14 years, I have developed shrink-wrapped PC software.

Most engineering tasks simply use principles that have been repeatedly applied to similar situations. As a result, most (not all) engineering tasks end up being a customization of a previously engineered task.

Software development is mostly (not completely) the opposite. Very few core business logic units are based on anything that has been previously engineered. This makes the task an order of magnitude greater more difficult. Software development is much like engineering the first bridge, whereas typical engineering adapts previous bridges to fit the current situation. Much of the time, software development is basic research.

Thus development deadlines are very difficult to correctly set. It would be very difficult for Edison to correctly set a completion date for the first lightbulb!

This is largely the position staked out by software project experts and troubleshooters.

David

-- Anonymous, August 15, 1999

The Mythical Man- Month

-- Anonymous, August 16, 1999

David wrote:

Thus development deadlines are very difficult to correctly set. It would be very difficult for Edison to correctly set a completion date for the first lightbulb!

I agree. But this works both ways. I'm not asking for accurate estimates if we can't have them. We can probably get better at that (speaking of both managers and programmers) but uncertainty is inherent. I can think we can live with that.

What we can't live with are the promises that are not kept. If the uncertainty was the only reason we would be as likely to finish early as late. The uncertainty should make us pessimistic estimators, not optimistic ones. Instead of saying a complex project will be finished in a year, we should say "We are targetting for a year, but realistically in the software game these targets slip. We can't say when it will be finished with any degree of accuracy or what it will cost."

This is what I did not hear as a middle manager. I was not trying to kill the project, or avoid paying for it, but I was trying to establish a reasonable price and a reasonable payment schedule. But the IT guys were always going to finish on time, and the price I paid assumed that the project would finish on time.

It never did. It was not the lateness, it was the promise that affected my negotiating position. If my budget reflected a new system implementation mid-year, I had to lay off people and structure the work (and training) around that assumption. By the time it became obvious that the system would not be implemented in time, it was too late to acquire the resources.

(The budget approval process in government made it impossible. We didn't have the money, and we would need the political process to get more. Halfway through a year? Forget it, unless it is a problem splashed on the front pages of the paper.)

All I needed was an acknowledgement that software projects were always late. Over time, this failure made implementing new technology way more difficult. The staff thought they got screwed every time. At the very best a new system meant months of scrambling with too few people, and a permanent reduction in staff. No wonder they resisted!

Tom

-- Anonymous, August 16, 1999

Hi Tom, Scott, et. al,

Interesting posts re project and management and the IT industry. However, my observations regarding project management cross most major industries. I have been previlaged to work in many diverse fields. I have truely seen the "good", the "bad", and the "ugly". I started my career as a PERT Analyst for the Ground Support Equipment on the Apollo Space Program. They had a 10 year development program with little time for schedule slippage. They had excellent contractor and government (NASA) management. There was open and honest communication. (One of the "good" projects.)

Another "good" project was the Sky Lab Program. I held the position of "Project Schedule Coordinator" for modifications at McDonnel- Douglas Corporation at thier Huntington Beach facility in California. For each specific "mod" a planning meeting would be held with functional departmental reps and someone from NASA. A member from the Work Defintion Group would give the attende's a copy of the scoping document. After the group reviewed it, I would plan and schedule the "mod" on a sheet of paper based on the statement of work. I then passed it around for review and comment. After everyone bought into the plan and schedule, they would sign and date it and I would issue it at the meeting.

Other "good" projects were two electric utilities that I did some consulting for as an Outage Planning Coordinator and one that I designed and developed a "Living Schedule" for as a result of the prepondance of required mods after Three Mile Island. The utilities were not only schedule oriented but held employes accountable as well.

One of the "bad" projects was as a senior planner for a mechanical installation contracor for a new nuclear power plant. The A&E would issue drawings that made absolutely no sense. For example, I remember the A@E issued a drawing for us to install a 16" main steam line from the reactor, across the parking lot, through the administration building and to the cafeteria. I told my manager that this was stupid. We would only have to take it out again sometime in the future. That's when he told me that I did'nt understand. THe company will get paid for puting the pipe in and they will get paid for taking it out! I quit soon after this incident.

But some of the "ugly" has to do with DOE. On a remediation project I was working on, to tell the truth was tantamont to not only being a traitor to the companies code of ethics but to be openly critized.

So what's my point? To ensure good schedules one needs openeness and honesty with all levels of management and the client. Does this environment exist in all the companies out there that are working on Y2K? I don'nt think so.

-- Anonymous, August 17, 1999

The good stuff is open and honest. What a simple and pervasive truth.

We could probably mandate the openness. But we can't mandate honesty, which is ultimately a personal issue.

Maybe if Y2Kis bad enough we'll get the open part passed as law, at least regarding utilities and some other things. Let's hope something good comes of it.

Steve

-- Anonymous, August 17, 1999

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl? msg_id=001Fum

-- Anonymous, August 17, 1999

Tom,

BTW: THANKS for all your insight to the human/technical issues on Y2K.

I'm an total failure when it comes to setting timetables for "basic research" software. The customization stuff is pretty easy; +/- a few percentage points is no problem. But I am horrid at "basic research" schedules. Lane posted a link to Mythical Man-Month above. I heartly Amen Fred Brooks comments. It's not that I want to hide behind irresponsibility; in fact, I'm humiliated and embarassed at deadline failures. Fred calls the problem Domain Complexity.

For me its like this: We spend days and days agonizing over project architecture, trying to illuminate each nasty corner of the problem. We start coding the effort. We *think* everything is OK because we are on Step 89 of 100 and all has gone according the plan. Marketing, Support, QA, ... everybody wants to know the status of the project. We are confident! Step 92 blows. Then we realize the issue invalidates Step 53 ... and then Step 23 ... In a matter of hours our project has gone from 92% complete to 23% complete. Why? Not because we were "uncertified" or "unqualified" developers ... we understand the tools just fine. We are *not* the experts on the problem to be solved. The best of us have become very good at asking questions, but the "devil is in the details" and it is very easy to overlook important points.

How can this be avoided. I don't know and I'm not sure that anybody else does either. The only real answer that I know of is to engineer the project on paper completely and then translate it into code. That's what NASA does with Shuttle code. They also spend about $1000 per line of code. Industry spends about $3 to $5 per line of code.

So the solution to the problem is: Ask me how long a project will take. After I have completed the solution (in code or on paper) then I can tell you! Otherwise, I am just guessing (if its "basic research" code).

Isn't that sad. If anybody knows a better way, write a book and tell us all how. In the meantime, I challenge anyone to find another solution.

Best regards,

-- Anonymous, August 17, 1999

One further comment: You can spend LOTS of money on a "paper design" and still not have anything to show for it. A couple of years ago, EDS spent several years and $40+ million of California taxpayer's money creating a paper solution for a student loan program. The stack of paperwork was unbelievable. My understanding is that is was totally unworkable and was completely discarded.

My colleagues and I (in Industry, non-life threatening software) generally opt to create architecture documents that are twenty to thirty pages in length then immediately start translating the solution into code. We have very frequent architecture meetings for course corrections. We find problems in a hurry, instead of waiting until the end to find problems. This has its drawbacks, but works pretty well under rapid development conditions.

-- Anonymous, August 18, 1999

Good comments, David. Thanks.

At times, when a project leader has asked "How long will this take?" I wanted to say "I'll know when I'm finished".

I vividly remember a snippet of conversation with another programmer. Must have been three or four years ago. Out of the blue, he turned to me and said, "I don't know about you, Lane, but sometimes I don't know if a modification is going to work at all until I've coded it and tested it." I figured he must have been asked "How long will this take?"

-- Anonymous, August 18, 1999

I've really enjoyed the thoughts posted here about project planning. Thanks to all for sharing your experiences.

I was reminded of Star Trek while reading. (Okay, so a whole lot of things remind me of Star Trek. *laughing* ) Forget about "Everything you need to know" being learned in Kindergarten. The only thing I learned there was that you get yelled at if you slide face first on your stomach down a slide. But Star Trek...now _there_ you could learn a lot.

Anyone else remember the Next Generation episode where Scotty is brought out of the transformer he kept himself alive in for decades after a crash? There's a lot of tension which evolves between Scotty and Geordi; the old experienced engineer who is out of touch with modern ways, and the younger engineer very knowledgeable but with less people-experience. There's one scene where Geordi informs the Captain it will take such and such amount of time to complete a fix.

Scotty asks, "So how long will it really take?"

Geordi replies with the same amount of hours he told the Captain.

Scotty, in complete amazement, says, "Ye told him the actual time? Are ye DAFT, lad?"

The point was that giving your actual best estimation places a burden on the estimator to be right, and allows no room for the unexpected. And if you estimate high, and are able to bring the project in sooner, then you come across as a miracle worker!

Posters here have evidenced this type of experience and it sounds like we could use even more wisdom-wise Montgomery Scott types in the planning field, huh?

-- Anonymous, August 18, 1999

I thought of the Star Trek episode, too, Bonnie.

Somewhere buried in this thread somebody talked about openess and honesty. I have no doubt that a history of bad communication between IT and management is a fundamental cause of Y2k.

I've got a lot more to say about that subject, but I'll start another thread with it.

Commander Scott was absolutely correct given his situation. A pessimistic outlook paid off for the chief engineer on the Enterprise. Over time, "natural selection" in the economy will turn most people in positions like that CE into pessimists.

But in the corporate boardroom, the objective is to sell the system. Optimism paid in that environment. There really was no downside to being optimistic. Pessimists did not get to sell systems.

Tom

-- Anonymous, August 18, 1999