Finally, there has been a small amount of substantive discussion of the Y2000 problem in the popular media, although most coverage continues to include only simplistic explanations and completely avoids (the dreaded) macroeconomics. Yet despite the media coverage, the public seems increasingly unconcerned about the problem. This summer, a National Science Foundation poll found the American public's concern about possible Y2000 problems was decreasing.

I once met James Harrington, who was "Mr. Reengineering" at Ernst & Young. We were talking at lunch after hearing a presentation he delivered. One of my colleagues at the table used the now-familiar phrase, "the customer is always right." Mr. Harrington had a different view on this -- one that has proven true time and again.

In the first two articles in this series (see 15 September and 13 October), I identified a maturity model for Internet technology adoption (below). This article focuses on how companies can move to Level 2.

Last week I discussed the future of packaged applications and components. I've had several comments about it, and I decided to take another cut, treating things a bit more abstractly.

I just returned from the annual meeting of the International Function Point Users Group (IFPUG). IFPUG is an organization dedicated to the idea of measuring software process, and once again they had a terrific conference. I presented a reprise of my "Avoiding Dysfunctional Measures," which explores how difficult it is to measure organizational activity, and how we sometimes assume things are working when they aren't.

As an industry, software design has a long history of projects that run long and over budget. There are three main reasons why this happens. First, project managers may attempt to set schedules and estimate work without a clear understanding of what the project involves. This is especially true when the project involves a desired result unlike any previously attempted by the project team. Second, tasks that should have been a part of the project plan are omitted, generally because of oversight on the part of the project manager.

What must a software manager know best? What knowledge is both distinctive and crucial for success in managing a software organization? All managers need to know how to manage people; that's not distinctive to software managers. Knowledge of technology is distinctive, but there are many examples of excellent software managers who are not technical gurus. What is it that produces the results by which a software manager is judged? Their software process.

At a recent conference on software development, I surveyed the 100 or so members of the audience who filled the room to hear about the dynamics of imposed deadlines and the impact on quality and reliability.

Every project manager needs to be a healthy skeptic. If I am not skeptical, I can get burned. If I am not healthy, I will burn everyone else and myself.