Whether a software organization succeeds or fails at changing its culture depends largely on leadership and the successful institutionalization of desired practices. Cultures capable of sustaining change and high performance respect, value, and support their people throughout the change.

As the aftershocks of the September 11 events continue to reverberate, many companies are hunkering down, tightening their belts, and cutting the budgets of projects that will not directly contribute to fourth-quarter profits.

On 14 November, IBM announced its support for the Object Management Group's (OMG) new Model Driven Architecture (MDA) and indicated that it would be including MDA in an upcoming release of WebSphere. This is a major boost for the OMG's MDA approach.

This seems to be the year for disasters. In the last three months, in addition to the September 11 disaster, I've seem three very large IT projects cancelled after the expenditure of considerable sums of money. One was in excess of US $50 million -- an ambitious Web project whose managers did not think it necessary to include performance modeling in the design.

In last week's Advisor, I discussed the growing importance of business process improvement in the age of e-business. Every company that seeks to take advantage of the Internet and Web to improve the way it does business must necessarily start by reviewing existing processes to see how they can be changed to take advantage of new activities that the Internet and Web can make possible.

It has become a sad cliche among Americans. Virtually all of us can recall exactly where we were and what we were doing on the afternoon of November 22, 1963:

The previous two Advisors outlined nine methodology design principles. This week will conclude the series on methodology design by adding eight common methodology mistakes to the mix. A number of these common mistakes come from Alistair Cockburn's work and new book, Agile Software Development.

In August 2001, Cutter Consortium surveyed 136 companies worldwide to get their thoughts on a range of project management issues. One question that is always of interest is salary.

Reviews, walkthroughs, and inspections are good practices -- resources. We can turn them into bad practices -- roadblocks. I've lived it both ways. I hope others can use some of the lessons learned.

The purpose of a review is to improve the product. We all make mistakes and other people can see my mistakes easier than I can.

A little more than a month ago I wouldn't have given a strange letter or package a second thought before immediately ripping it open. I sometimes receive mail that has some of the US Postal Service's suspicious signs: scribbled addresses, uneven and lopsided packaging, etc.