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.

This is the second in a series of three Advisors on methodology design.

One of the many consequences of the September 11 terrorist attacks has been a reassessment of priorities and values.

The notion of a "postmortem" is familiar to most software developers and project managers: at the end of an application development project, a report is written to document the good, the bad, and the ugly experiences, so that future projects can learn and improve. In theory, it's a useful concept; in practice, it's largely ignored.

Agile developers recognize that documentation is an intrinsic part of any system, the creation and maintenance of which is a "necessary evil" to some and an enjoyable task for others -- an aspect of software development that can be made agile when you choose to do so.

Over the past 10 years, the word "methodology" has become associated with ponderous, heavyweight, rigorous, process-, and documentation- centric processes for delivering software. While this has become the perception, a methodology can -- and should -- be much simpler.

Many experts have applauded the concept of speed to market. The fastest team wins in the competitive arena. While this may be correct in many cases, we should be careful in applying it as a hard and fast rule for new information technologies.

Any risk analysis should be undertaken by assessing the likelihood and relevance of risks and threats, but it is difficult to know exactly the extent to which the information and technical infrastructure of any building in any country is exposed without knowing who was responsible for undertaking and funding the attack on the World Trade Center (WTC).

A reader recently asked me to comment on the application of data warehousing and business intelligence (BI) in business-to-business (B2B) e-commerce. Therefore, I've decided to make this the topic of this week's Advisor.