Welcome to The Dunaway Group

Donna K. Dunaway, Ph.D., created The Dunaway Group to provide consulting services and training for organizations that need assistance in achieving benefits in the use of the capability maturity models®. Services have included initiating and progressing a process improvement plan, conducting appraisals of current capabilities, and moving forward with an organization's improvements in the most effective manner.

The Dunaway Group has provided training classes for the CMM® for Software and CMMIš to provide organizations better understanding of the maturity models and how the models may be implemented to improve development capability for both software and systems.

Published by Addison-Wesley in February 2005.
Marilyn Bush
Donna Dunaway

ISBN: 0-321-17935-8
Publisher: Addison Wesley Professional
Copyright: 2005
Format: Cloth; 304 pp
Status: Order Now

Dr. Dunaway was honored at SMU's 40th Anniversary of the Computer Science and Engineering Department of SMU's School of Engineering in November, 2007. She participated in the Distinguished Alumni Symposium and was presented the Pioneer Award for being the first woman student who earned the Ph.D. in the Computer Science Department.

Excerpts from her presentation in the Major Milestones panel at the Distinguished Alumni Symposium:

"Although I didn't cross the Rockies in a covered wagon, I consider myself a pioneer—at least in the computer industry and thought it might be interesting for you to hear about some of the early days.

In the mid 50's I graduated from TCU with a Bachelor degree in mathematics, I went to work at General Dynamics (called Convair at the time) in Fort Worth. Knowing nothing about computers except what I had seen on a game show on television, I had the opportunity to work in the computing laboratory that housed an IBM 704 that was state of the art in the late 50's. The B-58 delta-wing bomber was being built there at that time as a very high security project. I was very excited to have this wonderful million-dollar computer to play with as well as building a new airplane.

The IBM 704 was housed in a large room with raised floor and lots of air conditioning. My supervisor started me off with an Assembly Language Manual and a hand-drawn flowchart—saying, see if you can make this do that. There were no classes at that time to learn about computers or programming. It was all self-taught—or very informal on the job training. So, I did. It was lots of fun. Part of our challenge was managing with 4,096 words of memory. Magnetic core memory was encased in a large frame surrounded by glass. It looked to me like a beautiful piece of sculpture. Tiny little cores the size of the head of a pin, interlaced with beautiful copper wire. What a masterpiece!.

When I joined Humble Oil Research Center in Houston a few years later, it was somewhat of a come-down to work on a Bendix G-15 computer using paper tape input with even less memory. However, I later saw references in text books to my supervisor and office-mate (Peaceman and Rachford) for their finite difference methods for numerical solutions of partial differential equations that I had helped implement. Our debugging methods often meant replacing a small round punch into the paper tape and very carefully re-entering it into the tape reader.

Major milestones in the industry that will probably be mentioned by each of the panelists are the introduction of miniaturization via semiconductor memories in 1970 and in 1981 when IBM introduced the first personal computer making computing generally available to the public.

A few words about graduate school here at SMU in the late 60's and early 70's.

  • The computing facilities were situated in the frame building originally used by University Computing Corporation. We had a Univac 1108 that we all used for our computing requirements.
  • We carried around large boxes of punched cards with us and turned them into the computer operator who later returned our cards and the printed output our card deck had generated. My children entertained themselves at the key punches when I often stopped by the computing laboratory to make "another run" before hitting the fast food restaurants or Campisi's over on Mockingbird for dinner.
  • By the way, research was done at the library—no internet searches.
    • large index books where you found references to your topic, and then located the technical journal or book where your article of interest appeared.
    • no word processing capabilities at that time. My dissertation was produced on an IBM typewriter by a professional typist that I employed for the final version.

Through the years, I worked for several software development companies, including Texas Instruments in the 70's, and others in the oil and gas industry and telecommunications. Along the way I was never in a development environment that had a disciplined, structured, consistent way of building software. We were cowboys—and were good at what we did. But, of course, we had no idea that the work we were doing would survive and need to be modified many years in the future.

However, when I went to Pittsburgh, Pennsylvania, in 1992, to the Software Engineering Institute at Carnegie Mellon University, it was very refreshing to me to hear about the focus on process improvement—the actual techniques of building software that produced higher quality products with greater dependability.

The Capability Maturity Model for Software had recently been published as technical reports and later in hardback in 1994. The CMM was a set of guidelines for improving the development of software. The CMM was a collaboration of industry, government, and SEI staff to create a set of best practices for building software products.

All who had been in software development knew we had problems and difficulties in estimating schedules, requirements definition and inevitable changes, and maintaining systems that had not been intended for the long lifetime they assumed. So, the CMM made so much common sense; it was a pleasure to teach it to experienced industry professionals.

The CMM for Software reflects a 5-stage model of maturity, showing the initial level as the one where most of us had worked—competent people and heroic efforts to create the software products. The focus on moving up the maturity levels was:

  • Level 2—establishing requirements with a method for making changes. Incorporating consistent processes for project planning and collection of metrics that enabled historical data to be used effectively. Incorporation of quality assurance and configuration management. All the things we knew should be done in a software project—but actually documenting the processes by which things were accomplished—and following these processes consistently. This would provide a stable platform for projects to then improve what they were doing.
  • Maturity level 3 focuses on moving from project processes in level 2 to organizational processes. Maturity level 4 would have consistent processes and metrics with which to predict what effect certain improvements would have. Then, at level 5, improvement becomes a way of life for everyone in the organization. The defined processes can then be continually improved.

I found people very enthusiastic about this approach—although there was still lots to learn. Many organizations made significant investments in implementing the CMM and building their organizational process assets. Good results were reported in technical publications and conferences.

There were many capability maturity models being built for various application areas—primarily due to the success that had been exhibited by the CMM for Software. In 1998, an effort began at the SEI to add systems engineering to the software application, and CMMI (Capability Maturity Model Integrated) was created. I participated as a member of the original CMMI development team.

My primary responsibility at the SEI was the development of the SEI Appraiser Program and training qualified people to assess organizations against the CMM. Assessments were originally organizational interventions where an organization, through a team of qualified people, looked at their own processes as compared to the CMM and came up with an improvement plan suited specifically to their needs. This is contrasted with an audit that doesn't have all of the good organizational benefits as an assessment does.

The book I co-authored with Marilyn Bush was published in February 2005. We specifically wanted to focus attention on the way that an assessment could motivate positive change within an organization performing an assessment. Change is always difficult. When you are looking to improve your processes, the way you do business, motivating change is a very difficult aspect.

Experience had shown that when the assessment was performed as a collaborative activity within an organization, several things were accomplished:

  • broad participation involving both managers and developers in self analysis so turf issues were made visible and obviated.
  • focus on the process—not the people. A non-threatening way to have the developers doing the work actually examine their own processes with an eye toward improvement.
  • the resulting improvement plan would then be owned by the organization enabling change agents in the organization to then have some built-in participation and cooperation.
  • every assessment focused on an action plan—what happens after the assessment with buy-in created by everyone's participation in the creation of the plan for moving forward.

The work at the SEI was very satisfying to me because I knew we were benefiting organizations who were using our work. I value my many acquaintances of those highly-educated and experienced individuals who are in software development organizations all over the world.

If I have piqued your interest in process improvement, and I hope I have, I have given you the web address for the SEI (www.cmu.sei.edu) that has information not only on process improvement but on other SEI programs.

My hope is that a disciplined software development methodology, whether based on a capability maturity model, 6 Sigma, or something else, will one day be a part of the required curriculum for beginning computer science students to learn good practices so that they never have the need to become cowboys.

Although we cowboys did a lot of things right, software development is too critical an endeavor for cowboys."

Dr. Dunaway has recently become inactive in the process improvement (PI) community and sends very best wishes to organizations for continued success in process improvement endeavors and to colleagues who have contributed greatly in this area. To those who have come to this site seeking support for process improvement, please contact some of the many partners who continue to learn and improve methods and tools in this area. For the SEI Partner Network, see www.sei.cmu.edu.

Contact:
Donna K. Dunaway
dkd@dunawaygroup.com


© 2014 The Dunaway Group
®CMM, CMMI, CMM Integration and Capability Maturity Model are registered in the US Patent and Trademark Office.