Most software development projects don't practice what is usually considered "proper" software engineering practices: well-documented, traceable requirements do not exist, formal inspections are non-existent, analysis and design inodels are incomplete or not even done at all, and so forth. We know that many of these projects fail, and it is easy to blame the failure of the project on the lack of good software engineering practices ("If we only had well-documented requirements, a complete and thorough test plan, and formal schedules then we would have been successful!")But many projects that do not practice what many consider to be good software engineering practices succeed, and succeed famously. Examples include the startup introducing a revolutionary new product, the skunkworks project of an established firm that succeeds in changing the status quo, and selecting a mission critical application as the first OO application of a group just beginning to make the transition to the new technology.Gaining a deeper understanding of success and failure on software projects is absolutely essential for the continued maturation of our industry, and object technology in particular.

The key to making object technology work isn't technology. So what is it? This panel will cover a lot of the "soft" issues about dealing with people and teams. It's partly about managing software development, and mostly about doing it.