What makes configuration management (CM) professionals so unique? Is it the way we can view a complex task and break it down into meaningful activities? Is it the way we can bring some level of order to chaos? Is it that we not only want to understand the details on how things work, but we also like to understand the big picture? Is it our need to improve our environment? Or is it the way we persevere at difficult tasks in trying to bring together the pieces that comprise our deliverables?

Despite the fact that iterative approaches to software development are increasingly used, most of the people paying for IT software developmet have an expectation that we should be able to tell them—before coding starts—"what's it going to do, what's it going to cost, and when's it going to be ready?" This article exlains why that's an unattainable expectation and corrects the misleading "product-lifecycle-model" for estimating.

Over the years our industry has witnessed an explosion of maturity models. Last month I published a tongue-in-cheek column on this subject, "The Maturity Maturity Model™ (M3)." In this follow-up column, I hope to offer some actual constructive comments on the concept of maturity. For your reading pleasure, I included a list of thirty-four "Maturity Models" at the end. All thirty-four are real, including the "Broccoli Maturity Model." (You couldn't make this stuff up!)

The measurements described in this paper answer the question of whether Software Testing is "doing the right thing" (effectiveness). Once there is assurance and quantification of correct testing, metrics should be developed that determine whether or not Software Testing "does the thing right" (efficiency).