e-Talk Radio: Paulk, Mark, 28 November 2000

In other words, the good engineering techniques, the good management techniques that work for F16 or Microsoft or anybody else are the same kinds of things that have been done over and over again. And when I refuse to take advantage of those ideas, I'm hurting myself.

There are differences. That's certainly true. But good engineering and good management practices are good engineering and management practices. And a lot of the things that you've seen, extreme programming and lightweight methodologies and things of that nature, are in many ways repackaging of ideas that have been presented as good engineering and management practices many times before over the years.

Carol: Right. And I've heard that an excuse for poor management is not measuring, that if you can avoid measurement, then you can hide behind poor management practices.

Mark: There probably is some truth to that, yes.

Carol: Now one of the things that we had talked about is the fact that there are some things that the Software Engineering Institute has learned or that you've learned about high maturity organizations that aren't really captured in the current version of software Capability Maturity Model. Would you just expand on that a little bit?

Mark: Well there certainly are, in particular at the higher levels. When we published Version 1.1 in 1993, there were a number of things about Levels 4 and 5 that we had more of a theoretical understanding of than a practical understanding of. We had a very limited set of organizations that we were using as our models in terms of the best practices, if you will, for Levels 4 and 5.

And in the years since then, we've seen a growing number of organizations. There are about 85 Levels 4 and 5 organizations that we know about now. And we found out things that work. And one of the things that we see at Level 4, which is not captured in Version 1.1, is that it's not just process knowledge that you want to capture in a systematic way, it's also product knowledge. And so we see the Level 4 organizations doing systematic reviews. We see them doing domain specific software architectures. We see them establishing product lines and product families. We see them putting mechanisms in place that help them to capture product knowledge just like process knowledge. And that gives them a distinct competitive advantage in terms of understanding the work they're doing and in terms of understanding how to analyze and control their processes more effectively.

We also see a number of things in terms of how you implement the Level 4 and 5 practices efficiently and correctly and in particular controlling your processes at more of a process element level, keeping a balance at the systems level with the day-to-day process management issues, which is a balance between quantitative process management and software quality management more at the systems level. Those are all things that we have learned how to articulate better now. And hopefully as time goes by, we'll get that message out to folks through various training classes that we offer and through the CMM integration work that's going on now.

Carol: And you're doing a lot of work. There's so much work going on. And I can hear companies kind of saying: Well why would I bother? If it costs me money to go through an assessment, if it costs me money to put in these requirements and these plans, what's the benefit is the bottom line. What do I get out of this? Does it save money to do things