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.

In the first of this series, I identified a maturity model for Internet technology adoption as follows:

For the past few years, risk management has been a hot topic, and I would hope by now that every project manager has had some indoctrination regarding the importance of managing risks. It's relatively easy to make a case that prevention or mitigation of bad things is a good thing and to show that the benefits can outweigh the costs when you approach the process with some care and attention.