Skip to Main Content
Contact Us
Meeting Cancellation Policy

Established September, 1992

Newsletter of the Boston SPIN

Issue 8, January/February 1996

Return to Newsletter Index



FEB 13 (Tuesday) -- BCS Software Quality Group program Contact: Adam Sacks,

FEB 20 (Tuesday)-- Boston SPIN Monthly Meeting

Software Inspections

Several knowledgeable panelists will share their experiences in obtaining and sustaining management commitment and sponsorship, training practitioners and managers, preparing and disseminating Software Inspections artifacts, coordinating the transition effort, and collecting and using measurement data.


  • Jean MacLeod- Hewlett-Packard
  • Steve Bramley - Motorola ISG
  • Peter Harris - Sybase Inc.
  • Don O'Neill -Independent Consultant (Moderator)

6:30 PM (refreshments), 7:00-8:30 PM (meeting)
GTE, Building #5, 77 A Street, Needham, MA
(Admission Free, Wheelchair Accessible)

MAY 20-23,1996 -- 8th Software Engineering Process Group (SEPG) Conference, Atlantic City, N.J., "Broadening the Perspective for the Next Century"

Back to top


We have started a Job Bank bulletin board at meetings. Job opportunities may also be submitted to this newsletter. See the new "Job Bank" section.

There is no report for the November 95 meeting; the December meeting was snowed under. The January meeting topic was Cleanroom Engineering and the speaker was Alan Spangle of IBM's Cleanroom Software Technology Center. A report of that meeting will appear next month, but if anyone wants information in the meantime about CSTC's programs they can contact Alan at 301-803-2763 or email:

Back to top


October 1996 Meeting Report
by Ed Maher, courtesy of Digital Equipment Corporation


How Can I Get My Manager and Organization to Buy In to Software Process Improvement?


Dale Emery (independent consultant)


Neil Davies (DEC)
John Howland (EMC Corp.)


The two presenters took different approaches to the topic. John focused more on what happens once you have management support. He made the point that management support is not as critical a factor as most people make it out to be, and that it is helpful to begin by focusing change on yourself and things that you control before attempting to influence change in others. Neil addressed many aspects of process improvement including how to get management support. He also identified some key attributes of a successful program.

Dale Emery's Experiment

Dale started off the evening with an experiment. He had us all stand up, pair off, face each other, and place our palms together. He then asked the taller person in each pair to push. After about 5 seconds we were told to sit back down and he asked the people that were being pushed what they did. The resounding answer was that we resisted (I was a "pushee".) Most of us could not explain why we resisted (he did not tell us to resist). The lesson from this experiment is that resistance is natural. We should expect it, not get defensive, and treat it as an opportunity for gathering information.

John Howland's Presentation

John Howland then got up and started right off by saying that he has had the luxury of always having management support, but that it does not always guarantee success.

He stressed that if you want to be a change agent, it is healthy to begin by first introducing a change into your own behavior. To help with this, he suggested that we ask ourselves the following:

  • What steps can I take to improve my skills?
  • Where have I documented my processes?
  • What metrics do I use to measure my effectiveness?
  • What have I done to foster innovation in myself?
  • To illustrate this point, John put up an appropriate Mark Twain quote:

Nothing needs improvement so much as other people's processes.

Related to this was his recommendation that when first attempting to introduce change into an organization, choose something clearly within your own control. This is more likely to succeed and can then be leveraged to help introduce change to others.

Addressing senior management's role in change, John made a case for treating senior management not as an asset, but rather as a risk that needs to be managed (even when they are strong supporters). His concern is that senior management can derail an initiative with an off-hand remark or slip of the tongue. John felt that he does not want them against him, however his preference is for them to be supportive, but out of the way.

(I am skeptical as to how this philosophy would hold up if senior management was not solidly behind the activities. I believe that a knowledgeable and visibly supportive senior manager can be a very positive influence when trying to introduce change, and one that is perceived as disinterested -- by being "out of the way" -- can make it difficult to succeed.)

John's recommendations on how to get support from the organization and how to successfully manage change revolved around managing culture (though I don't remember him using that word). Specifically, he stressed: doing gap analysis of the current state with the desired state, building awareness, and aligning the objectives of the change with the objectives of the organization.

He also reminded us that we should recognize resistance as being a natural response to proposed change. This is due to many factors, including: process inertia, no perceived problem, or the change being unaligned with the organization's goals.

John made an interesting observation involving the introduction of new technology into an organization. Engineers frequently are on the leading edge when it comes to accepting (embracing!) new tools into their environments (such as upgrading to Pentium or Windows 95), but frequently have the opposite reaction to the introduction of new processes.

As a summary, John presented his "lessons learned":

  • When trying to introduce change, look inward first.
  • Begin by taking action on things that are in your own control.
  • Sell the problem as a way to get people involved in the solution.
  • Solicit and use input from the organization.
  • Reinforce with positive feedback.

Neil Davies' Presentation

Neil Davies took a slightly different approach to the topic, speaking in more general terms. His conclusions were based on his experience in two companies both as a change agent and as a sponsor.

(A terminology point: Neil equated "senior management" with "sponsor" and then discussed dealing with sponsors.)

He did not go as far as John in downplaying the importance of management support -- pointing out that it is important, but that it is only the first step. Neil does not see it as the silver bullet that many people make it out to be, and noted that getting the buy-in of leaders from the technical community can be equally important.

Neil addressed the question, "How do you get sponsorship?" He said that the best case is if you can negotiate sponsor behavior before signing on as a change agent. Get the sponsor to commit their time, provide the right people (not just the budget), and link the proposed change to business goals that the sponsor understands.

He listed some different approaches for selling an initiative to a sponsor. These included: picking an industry religion (SEI, ISO 9000), identification of trade barriers that need to be overcome (ISO), or tying it tangibly to business goals. He did not advocate any one of these over another (and there were more); his point was the importance of picking one and sticking with it.

To sustain a process initiative and produce change, he identified three things that are crucial: accountability, involvement by everyone, and being able to measure the results. Addressing each of these:

  • Accountability

    The initiative should be designed so that individuals can not ignore it and still be perceived as being successful in what they do. Once implemented, the proposed change should be integrated into the Human Resource system. There should be positive reinforcement for those who follow the change.

  • Involvement by Everyone

    A process improvement initiative cannot succeed in a vacuum. All levels of the organization have to be informed and involved in what's going on. The success of the improvement "project" should be as important to the organization as is shipping product.

  • Metrics

    Any process initiative has to be designed to have clear measurable goals that relate to the business. These should be tracked (actuals against goal) and analyzed. This tracking and analysis can then be communicated across the organization as one way to convey results/action.

(After all, this is no more than we ask of software development projects at Level 2.)

Neil had an interesting recommendation for people who are chartered to be change agents: "Get a day job." If all you do is process improvement, then you can frequently find yourself on the outside looking in. If you have some direct responsibility in the organization that involves shipping product, then you are already involved, and you can switch hats when warranted.

Since Neil has been a sponsor, he took the opportunity to explain some things that help a sponsor be successful:

  • A critical mass of their management team needs to be on board and behind the change.
  • They need to be patient and allow time for people to come around.
  • Give some explicit attention to formal education.
  • Tactically, there needs to be some short-term success to leverage.

Discussion Period

Neil's prepared comments were followed by a free-for-all question and answer session. It was different from the usual SPIN Q&A in that the audience was encouraged to participate in the answers as well as the questions. I am not going to try to convey the flow of information and I did miss some of the extended discussion that resulted from these questions.

Q: Do you think that we should have another term for "process improvement" (it has developed a lousy connotation)?

A: John thought that rather than calling out "process improvement" it should be treated as being just part of the job.

(This is a suggestion that I have heard other people make, and it is a good philosophy. But I also think that most organizations need some explicit management of their process improvement initiatives. It is difficult trying to have it both ways; on the one hand stating that process improvement is just part of the job, and at the same time having an infrastructure for planning, tracking, reporting progress, and rewarding around "process improvement".)

Neil suggested that if the terminology was getting in the way, then another term should be used.

(I think that trying to wordsmith your way around resistance is not worth a lot of cycles. It has been my experience that regardless of an individual's opinion of process improvement, they will recognize it when they see it.)

Q: What do you think of a senior manager stating that since their organization got ISO 9001 certified in one year, they should be able to achieve SEI Level 3 in a year?

A: Neil thought that this was a fair assumption given that ISO certification is loosely characterized as being equivalent to somewhere between Level 2 and Level 3.

He also mentioned that process improvement should always be done on its merit. If you are implementing a CMM- and ISO-based program, then implement the initiative in its own context and independently track the ISO or CMM coverage wherever it is appropriate.

There was some discussion around the merits of the two schemes (and of goal-based process improvement in general). ISO 9001 is high level and applies to many domains; the CMM is fairly detailed and is focused on software engineering. This leaves open the possibility (getting back to the original question) that there could be significant work going from ISO 9001 certification to Level 3 -- depending on how they implemented the details.

Q: Can each of you list three improvements that you have observed that were put in place without management support?

A: Neil said that he has seen formal inspections and the use of path coverage tools be successful without support. He also briefly described an initiative that a development group at Digital did on their own to improve the process for handling problem reports (this was presented at this year's International Conference on Software Quality in Austin TX).

John described some tool acquisitions that were driven bottom-up without management support.

Q: How do you handle the fact that no one has time for process improvement?

A: John thought that it is important to get the change introduced early in a project's life-cycle so that the introduction of the change can be part of the project plan.

Neil suggested that getting some visible improvement on the current release is a great selling tool.

Ed Maher works for Digital Equipment Corporation within the Open VMS Engineering organization.

Back to top

about his new book, "ISO 9001: Interpreted for Software Organizations"

Ron Radice, of Software Technology Transition, has recently published the book "ISO 9001: Interpreted for Software Organizations" In the book's Foreword, Watts Humphrey says, "If you are interested in ISO 9001 you should use [this book]." IN THE SPIN shamelessly took advantage of the fact that Ron is a Boston SPIN member to ask him some behind-the-scenes questions.

Summary of contents (352 pages):

  • Foreword -- Watts Humphrey
  • 1 -- intro to ISO, ISO 9000, quality, quality systems
  • 2 -- quality management systems (including what to be sensitive to when developing a QMS)
  • 3 -- audits and getting to registration (including avoiding overkill)
  • 4 -- interpretation of each of the 20 clauses in ISO 9001, including the full language of each clause
  • A -- auditor's checklist
  • B -- list of quality records, quality documents, and audits/reviews required by ISO 9001
  • C -- example of a nonconformance record
  • Glossary
  • Acronyms
  • Bibliography

ITS: When did you first get the idea for writing this book, Ron?

Ron: I was still at Groupe Bull when I first thought a book on ISO 9001 was needed. However, I put it aside when I went to work at the SEI. I completed it when I left the SEI and then it came out in print in August of last year.

My primary concern was that ISO 9001 was significantly vague or amorphous enough that software people were having more questions than they were getting answers for from those in the ISO 9001 community. I saw this even in the training I received to become an ISO 9001 auditor. I think this vagueness is still true enough for most software people. The ISO standard, even the new version issued in July 1994, does not sufficiently lend itself to software design and development, much less maintenance, without specific interpretation.

I thought I could help clarify some of the issues and questions software people might have. As I saw more of what other companies were doing with ISO 9001, I developed an additional concern with the standard -- some companies were getting certifications, but they were without a doubt a "mud-sucking" Level 1 when they were getting assessed against the CMM. When I would ask how could that be, I was told, "You can fool the auditors."

Every time I thought about this type of comment, I thought "What a waste of time and money," but then I'm a quality bigot. I thought more could be done by those companies going for ISO 9001 certification where they could also help themselves improve their product and process quality and not just go for the certification. So my second purpose became a quest to position ISO 9001 as a quality tool that could be used as a first step, but never as the final step.

By the way, one of the reasons I think some companies are "fooling the auditors" is because the badge of certification seems more important as a marketing position than trying to do something significant with quality. This is not to say that the auditors can apparently be fooled. I'll stop here before I get myself too much in trouble with the ISO 9001 community. Well, before I stop, let me add that I think it is unfortunate what is happening in the ISO 9001 world, since this problem is apparently not limited to the software community. It is unfortunate because ISO 9001 is actually not a bad first step. The people I have a lot of respect for in the ISO 9001 community will state that ISO 9001 is a set of minimal requirements for quality. The people I try to avoid are the ones who think ISO 9001 is everything that is needed. It simply isn't, but it is a good step in the right direction.

ITS: What do you think are the book's unique features?

Ron: It tries to give a generic interpretation and then a software interpretation. Then it states some risks that software suppliers might encounter if they do not address the ISO 9001 requirements. The book views the ISO 9001 requirements as basic quality requirements, not as something specific to ISO.

ITS: How would you relate it to other well-known books in the software process field?

Ron: Boy, that's an odd question. One thing I've tried to do was get experts and users to review the book before it was published. It was reviewed by over 20 people in six different countries, so I think I got the "international" flavor it needs to be a book that could be helpful for ISO and software suppliers. The other thing I've done is to open the book up to the readers to give me feedback, pro and con. I'd like to have a second edition with the influence and participation of the user community. This is much like an Internet approach to shared development. Although I wrote the book, I see myself more as voicing what the community is concerned with and what they have as issues.

To address your question, however, I'd like to think that this book will take a useful place along with the "other well-known books in the software process field", but only time and the readers will show if this is meant to be. I should add that while the book does focus on ISO 9001, the readers will find a generic process discussion included. I think this will be useful to them beyond ISO 9001.

ITS: What was the most enjoyable aspect of researching and writing it?

Ron: When I started doing research, I was surprised at how many of my issues were also perceived by others. Their views and comments helped me focus the book to both admit the issues with ISO 9001 and then permit that ISO 9001 could be used as a path to achieve better quality. The other part I enjoyed was learning. I now know more than I did when I started and I don't mean this in the obvious way. I truly believe that introspection, which writing causes me to do, helped me crystallize on other subjects of software engineering and process. As a result there are other books I am working on.

ITS: Which parts do you think you will want to / wish you could rewrite soonest, and why?

Ron: I think I would add more to the risks sections. I've since found that discussing the risks in some of the training we've done gets people to open up about many other problems they are having or are concerned with. It seems to kind of lead to a stream of consciousness about doing software as a business. It always amazes me how many problems software organizations all have in common and yet each organization is unique. I like getting people to find ways for them to be able to first acknowledge the issues and then find the answers for themselves. So much is common sense in both ISO 9001 and the CMM, and people just seem to need a bit of a directive push to see the common sense. I think the risks sections helps in the same way, but I would have done more here.

ITS: What chapters do you wish you had time to include, but couldn't?

Ron: I would have liked to compare ISO 9001 and the CMM. The new version of the standard is better than the original and I've not yet seen anyone make a CMM comparison to the new version. I would also have liked to do a Malcolm Baldrige National Quality Award comparison, although there is an excellent one that NIST did a couple years ago. I would build on what they did. Both of these chapters were deferred since the book had already gotten up to 352 pages as is and I am always concerned when software process books get too big. I fear that people buy them but really don't use them. I hope I'm wrong. And I did want this book to be used.

ITS: What is your next writing project?

Ron: There are two books in active work. One of them is long overdue and the market already has a number of good books on the subject: inspections. But I feel I need to do this one, since I worked with Fagan in 1972 and actually moderated the first inspection. I see this book as a labor of love. I will be adding some sections that discuss the pragmatics, how metrics play a key role in success, limitations, and not just the benefits of inspections.

The other book is a set of case studies on software data and metrics. This one I am having a lot of fun doing and I think it will be different enough that it will meet a need that many organizations are having getting started and seeing benefits in relatively shorter time frames than many software process people think is possible. But it is possible, and I'd like to share that.

By the way, I am always looking for people who would like to review or make suggestions for these books, so I invite your readers to contact me if they have any ideas they want to share.

Ron can be reached at He notes: "As you may know, for Boston SPIN members, I will pay postage to any orders and reduce by 10%. Additionally, members can go to SoftPro and get a 10% discount."

Back to top

(Judi Brodman)

New Year's Greetings, SPINners:

First, I hope that you all had an enjoyable holiday season. I look forward to the holidays because it's the only time of year that all of my family is together. We really enjoy celebrating together after which everyone goes home and life returns to "normal". Our work life can be somewhat similar -- we have periods of exhilaration when we are on a challenging project and are part of a team that works exceptionally well together, and when pride and enthusiasm are commonplace. At the end of such a project, there is a wonderful feeling of success and the feeling that we have been part of a truly great experience. Then everyone is assigned to something new and work life returns to "normal". As a result of these experiences and the lessons we take away from them, we change the way we approach and work through many new challenges. But isn't this what process improvement is all about? Document the successes and the failures of your projects as they happen, learn as much as you can from them, discuss experiences during and at the end of each project, and apply the lessons as soon as possible.

To Paris, France: your question was as follows: "I am trying to calibrate the COCOMO model to make effort and schedules estimates. Can you tell me if there are some simple tools/scripts I can use to count # of lines (C, C++, Pascal and 68K Assembler)."

I contacted Barry Boehm because he would have the best information concerning the COCOMO model. Barry answered:

There are C Source Code Metrics located at:

Also try these news groups:

comp.lang.c comp.lang.c++ comp.lang.pascal comp.sys.m68k.pc

For our COCOMO 2.0 project to develop and calibrate a 1990's-2000's version of COCOMO, we are using the Amadeus commercial metrics package, which has templates to ensure that everyone counts code consistently. More information on Amadeus is at -- Barry.

Let me know if you have any further questions in this area. Good luck!

Because The SPIN Doctor is now a year old and is reprinted in many newsletters around the world, this is an appropriate time to repeat the working details of the column. The format of the column is similar to the "Dear Ann Landers" column. You, the reader, send your questions or comments on process improvement to me; I, in turn, answer as many questions as I can, calling on experts such as Mark Paulk, Ray Dion, Watts Humphrey, Bill Curtis, and Barry Boehm for help when needed. If you request anonymity, I restate your question or comment in such a way that it will not identify you. I look forward to hearing from you.

Now that I have explained how the column works, I'm going to change my approach for this one time because I think that you are the real experts in the following area. The return-on-investment (ROI) column of several months ago spawned more questions on ROI. Some of you are working on projects or task-oriented contracts for which customers have asked for ROI indicators. You ask about the correct way to obtin these, but you don't know what your process improvement investments are for the project. Most of my work has been at the organizational level, and I do know that the same steps that apply to organizational ROI hold true for project ROI:

  • Define investment(s) (effort, $$, etc.)
  • Define return(s) (metrics, $$, etc.)
  • Define the representation mechanism for the return(s)
  • Create a footprint (baseline)
  • Track investments
  • Collect return data
  • Calculate ROI

But this requires knowing the effort, resources, and so on, that are being spent for process improvement on your project. I ask anyone who has experience with a task or project approach to ROI to share what you have discovered with the readers of this column -- and to include the failures as well as the successes.

A final word -- we just observed the 10th anniversary of the Space Shuttle Challenger Flight 51-L disaster on 28 January 1996. We lost seven true adventurers. As we approach the 21st century, the frontiers left to conquer are few -- and the adventurers left to conquer them are fewer. As I said earlier, we tend to learn only from our successes -- we tend to want to forget the disasters. In this case, let's remember how these seven lived -- Reach for the Stars!!

This column is for you; let's make a difference!! Send your comments and questions to or directly to the Editor: Sign them or use a "pen-name" -- I respect your confidentiality!!

-- The SPIN Doctor

Back to top


Part-time instructors wanted

  • Immediate need -- Advanced Programming in "C", Thursday evenings
  • Future needs -- Visual Basic, "C++", Data Communications, Systems Design/Operating Systems, and others

Send resume to P. Getch, Chair Business Division, Massasoit Community College, Brockton, MA 02402 or call 1-800-CAREERS, ext. 1670

ACSI is an internationally recognized leader, providing simulation systems to the US and other NATO governments for over thirty years. Our continued expansion has created several openings on our Burlington, MA based Technical Staff. We are seeking talented Software Development Professionals with expertise in the following areas:


The qualified candidate will have 3-5 years experience with C, UNIX, X-Windows/Motif, as well as some experience in a Windows environment. Also desirable is familiarity with CASE Tools and device Drivers.


We are seeking an individual to perform Configuration Management duties, and also double as a Software Engineer. The successful candidate will have 3-5 years experience in configuration management, software release control, C programming, UNIX, and some exposure to CM tools like Atria's Clearcase.

ACSI has openings on both a permanent and contract basis. For consideration, please forward your resume to: ACSI Human Resources, One Van de Graaff Drive, Burlington, MA 01803. Visit our Web Site at


Computing Devices International (formerly Control Data Corporation), a provider of high quality, electronic information systems for commercial and defense industries is seeking an individual to lead the definition and deployment of software development processes throughout its U.S. Operations organization headquartered in Bloomington, MN. Reporting to the Vice President of Quality, the successful candidate will be self motivated and directed and will employ a process management focus embracing innovation and non-conventional thinking to mature the organization to a Level 5 rating as defined by SEI CMM.

Requirements include a working knowledge of software engineering, experience with deployment of SEI CMM in an organization, program/project planning, oversight and tracking, excellent communication and people management skills.

Computing Devices International offers competitive salaries and comprehensive benefits. For consideration send or fax your resume to:

Human Resources Attn: KEK
Computing Devices International
8800 Queen Avenue South
Bloomington, MN 55431
FAX (612) 921-6245

An Affirmative Action Employer

Back to top


The Boston SPIN is a forum for the free and open exchange of software process improvement experiences and ideas. Meetings are usually held on third Tuesdays, September to June.

We thank our sponsor, GTE.

For information about SPINs in general, including ***HOW TO START A SPIN***, contact: DAWNA BAIRD of SEI, (412) 268-5539,

Boston SPIN welcomes volunteers and sponsors.

For more information about our programs and events contact: CHARLIE RYAN
Technical Assessments, Inc.
ESC/ENS (Bldg 1704)
5 Eglin St
Hanscom AFB MA 01731-2116
(617) 377-8324; FAX (617) 377-8325;

IN THE SPIN is published monthly September to June, occasionally bimonthly (qed). Letters, notices (including job postings), and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors.

IN THE SPIN is available only by email. TO SUBSCRIBE send email address to

SEND letters-to-editor, notices, job postings, calendar entries, quips, quotes, anecdotes, articles, offers, and general correspondence to Sallie Satterthwaite, (508) 369-2365, If possible, please format input as text with explicit line breaks and the maximum line length seen here. Send SPIN Doctor questions to the address given in the SPIN Doctor column.


The following will also work:

HTML formatting by Thomas E. Janzen.

Return to Newsletter Index

Back to top