Skip to Main Content
Contact Us
Meeting Cancellation Policy

Established September, 1992

Newsletter of the Boston SPIN

Issue 12, January 1997

Return to Newsletter Index



JAN 21 (Tuesday): Boston SPIN meeting

Panel: Achieving Higher Maturity Practices
Dan Nash (Raytheon)
Bob Spillane (IBM)
Stu Jeans (Lockheed Sanders)
Albert Soule (Arthur D. Little)
GTE, Building #5, 77 A Street, Needham, MA
Info: Ken Oasis, (617) 563-4197, or email:


A series of presentations and discussions regarding software quality
Friday, Jan 24: Richard DiMillo (Bellcore)
Friday, Feb 28: Stu Feldman (IBM)
Friday, Mar 28: Ed Miller (Software Research, Inc.)
Times and locations to be announced. [The November event was a morning session in Waltham, and was free.]
Sponsor: LASER (Laboratory for Advanced Software Engineering Research), U/Mass Amherst, Department of Computer Science
Info: Wendy Cooper, 413-545-2475,

MAR 17-20, 1997 -- SEPG Conference

"People - Process - Technology: Stuff That Works"
San Jose Convention Center, San Jose, California
Contact: SEI Customer Relations, 412-268-5800
FAX: 412-268-5758

APR 1 -- First Annual Software Quality Institute (SQI) Symposium

"Software Reliability Engineering"
The University of Texas at Austin, Austin, Texas
Contact: (800) 687-8012 or (512) 471-4922

We have 2 separate email lists: one for this newsletter and one containing LOTS of announcements that we receive from process organizations and forward out. To add yourself to the announcements list send email to Charlie Ryan

Back to top


Would you like to talk with other software professionals about issues related to software process improvement focused on the SEI Capability Maturity Model?

I am interested in creating a means for SPIN participants to meet outside the monthly SPIN sessions to discuss issues around process improvement and implementing the CMM Key Process Areas (KPAs). My personal focus is that I am the SEPG lead for a software organization implementing the Defined (Level 3) KPAs, but I certainly believe the focus of any group needs to be wider than Level 3 issues. The benefit I look for from such a group is to provide an opportunity to discuss real world software process improvement issues and potential solutions on an informal basis. I would like to hear how other organizations are addressing process improvement issues and I am willing to share my organization's experience.

If you are interested in creating a group to discuss software process improvement issues, please contact me. The format and time of any meetings are totally open for discussion. In the next newsletter, I will send out a summary of the response (if any) to this notice.

Hope to hear from you!

Stan Ostrowski
Dynamics Research Corporation, 60 Frontage Road, Andover, MA 01810
508-475-9090 x 2236,

Back to top


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


Managing Resistance to Software Process Improvement


Dr. Chuck Myers, SEI


Dr. Chuck Myers from the Software Engineering Institute gave a streamlined version of an all-day tutorial that he did at the recent SEPG Conference in Atlantic City. He covered:

  • Some foundational thoughts (ways of thinking about resistance)
  • Characterizations of resistance
  • Characteristics of the technology (of process improvement)
  • Sources of resistance
  • Characteristics of those that resist
  • Planning for, and managing resistance

This was a lot of material in a short time. Even though he did a good job with each of the topics, the transition and flow were a little rough, and there wasn't much time for Q&A.

Some things that I took away:

  • The importance of anticipating resistance, understanding what's behind it, and respecting those underling reasons. This can allow for effective management of the resistance to a successful (win-win) conclusion.
  • He also made a very good point about not dwelling on things that can't be controlled. Energy is much better spent designing solutions so that they leverage those areas in which you have influence.

Back to top



He started out by citing a couple of examples of resistance through history. The one that I liked was from an 1829 letter from the Governor of New York (Martin Van Buren) to the US President (Andrew Jackson). In the letter, Van Buren lists a number of reasons why the US should not encourage the use of railroads, including: 15 mph is too fast for anyone to travel; trains will scare women and children; railroads would have a negative economic impact on the steamboat industry. (The Governor of New York cared a lot about the steamboat industry, given the location of the Erie Canal.)

Dr. Meyers then asked the audience some questions:

  • What are people resisting?

    - "Change" was the consensus answer.

  • Why are people resisting?

    - Answers included: fear, no time, and no motivation ("It ain't broke.")

  • What does resistance look like?

    - A lot of answers came out, including: being ignored, lip service, striking out at the messenger, and criticism of the details.

  • How is resistance affecting you?

    - Answers included: slowing the work down, frustration and pain.

He emphasized that resistance cannot be forcibly overcome. The harder someone pushes against resistance, the harder the push back will be -- or worse, the resistance will go underground to fester and resurface later.

Dr. Meyers then described a concept involving our "Circle of Influence" and "Circle of Concern". These concepts are from "The Seven Habits of Highly Effective People," published in 1989 by Steven R. Covey. Conceptually, these circles contain things that are in our way. The Circle of Concern contains those things that affect us and that we can't influence (for example, the weather). The Circle of Influence contains the things that we can influence (our own activities, for example). It is important to focus energy away from the things that we can't influence and onto things that we can.

A common mistake is to become frustrated and start dwelling on things that can't be directly controlled. ("If only senior management would show more support." "We can't succeed because people just don't have the time to pay attention to this.") The key is to know the things that can be controlled, and to achieve success by affecting those things.

He briefly pointed out how important it is for change agents (people working to bring about change) to be trustworthy. Since trust is something that has to be earned, he identified some things that a change agent can do to earn trust. These include;

  • Ensuring that the focus stays on the facts (and not on personalities)
  • Working toward win-win situations
  • Always being constructive
  • Understanding and respecting the affected people

Back to top


To introduce a discussion on the inevitability of resistance, he presented Myers' Rules for Understanding Resistance:

  • Rule 1. People behave like human beings.
  • Rule 2. When in doubt, refer to Rule 1.

The point is that people have a strong instinctive behavior to be mistrustful when confronted with an unknown (such as a process improvement initiative).

It's also important to understand exactly what it is that's being resisted. An obvious answer is the outcome (the consequence of introducing the technology). But that isn't always the case. Some people resist the individuals who are pushing the change, or the way that the change is being implemented, or (instinctively) they're just resisting change because it is change. If you don't know what's being resisted, then it's hard to deal effectively with the resistance.

He described two possible resistance cycles that groups and individuals can go through as they work through a change:

  • Positive Resistance Cycle--

    Uninformed certainty, informed doubt, resistance, realistic concern, and informed certainty

  • Negative Resistance Cycle--

    Status quo, stunned paralysis, denial, anger/rage, bargaining, depression, exploration, and acceptance

(The negative cycle is also known as the Grieving Cycle; it applies to people dealing with personal tragedy.)

The negative cycle is harder to deal with, can take much longer to work through, and can frequently stall out -- never getting to acceptance. He also pointed out that once someone is in the negative cycle, it can't simply be started over; it has to be worked through.

The cycle that people end up going through can be influenced by the approach taken when introducing a change. A key thing when trying to guide people toward the positive cycle is to involve them as much as possible in the definition and introduction of the change. If a change is simply imposed, then the negative cycle is more likely to kick in.

Back to top


Addressing some characteristics of the process improvement technology, he described the concepts of Innovation versus Improvement.

  • Innovation is a dramatic and revolutionary change that occurs quickly
  • Improvement is a more subtle and evolutionary change over a long time.

When attempting revolutionary change (innovation), he recommends that a lot of attention be given to setting the right foundation. Using the SEI IDEAL model for process improvement initiatives as a backdrop, he said that IDEAL's Initiating Phase should be followed (this phase includes: identifying the stimulus for improvement, setting context, establishing sponsorship, and establishing an improvement infrastructure).

With the more gradual evolutionary change (improvement), this up-front infrastructure and discipline may not be necessary.

Back to top


Change can affect individuals in a lot of different ways:

  • Professionally, it can affect how people work.
  • Personally, it can affect things outside the workplace.
  • Socially, it can affect an individual's direct relationships with others.
  • Culturally, it can affect indirect relationships with others.

And speaking of culture, Dr. Meyers touched on culture and paradigms. He defined culture in this context as a pattern of shared assumptions, and referenced Joel Barker's definition of a paradigm:

  • A set of unwritten rules that:
  • Establishes or defines boundaries
  • Tells us how to behave within the boundaries to be successful

Paradigms can create filters through which things are seen, resulting in misunderstandings and miscommunication. He described three levels of filtering that data or facts can go through as we all interpret what we see:

  • Culturally ascribed meanings
  • Personally ascribed meanings
  • Theories, knowledge, & assumptions

The result is that two people observing the same event can have drastically different perceptions of what occurred.

Back to top


He presented two models to represent how organizations can react to a change. The first is an Ogilve Curve showing how commitment to change is demonstrated. The second, called the Adopter Continuum, defines personality groups for accepting change (people can be typed according to why and how rapidly they accept change). These are summarized as follows:

  • The Commitment to Change phases are: Contact, Awareness, Understanding, Trial use, Adoption, Institutionalization, and Internalization.

    - Dr. Meyers focused on the "Awareness" stage as being crucial. It's easy to get stalled at "Awareness". At that point, people have enough knowledge to talk about the change, but it's difficult to assess whether they really understand what they are saying.

  • The Adopter Continuum identifies the following individual characteristics of those accepting a change over time:

    - The Innovators buy in right away. These people are usually enthusiastic, but don't have the power or the money to effect further usage. To get to them you should focus on the technical merits and not bother with any marketing.

    - The Early Adopters are the mavericks or risk takers. They can see the potential, but don't have credibility with the majority. To win them over, you should focus on business potential, and structure the program with many tangible deliverables. (On the graph, the Innovators and Early Adopters combined made up one sixth of the population.)

    - The Early Majority are the pragmatists, hard to win over but loyal once won. They need to see other people's success before they'll come on board. (The early Majority made up a third of the population.)

    - The Late Majority don't want any risk, and will wait until something has obviously taken hold. To influence them, you should emphasize the maturity of the change and present a complete solution. (The Late Majority made up a third of the population.)

    - The Laggards are the skeptics; to get them you need to find out something that they are excited about and find a way to integrate it with the change. (The Laggards made up a sixth of the population)

The Adopter Continuum is taken from "Crossing the Chasm" by Geoffrey Moore. The chasm is the gap between when the Early Adopters come on board and when the Early Majority kick in.

Back to top


He went fairly quickly through a couple of slides on how to incorporate resistance into a plan and how to manage the resistance as it unfolds.

  1. Planning for resistance:
  2. Address resistance explicitly.
  3. Predict and verify the objects and sources of the resistance.
  4. Identify trends and themes in the data.
  5. Involve the people who will be affected (avoiding the negative resistance cycle).
  6. Develop strategies based on specific interests and roles. (Need to identify what gets people excited and tie the change to that. However, this linkage can't be artificial.)
  7. Develop strategies for groups and for individuals.
  8. Remember that people often resist for good reasons. (They have their own valid and unique perspectives.)
  9. Treat resistance as an opportunity.

Managing resistance:

  1. Create safe environments.
  2. Provide many feedback channels.
  3. Involve the people who are affected.
  4. Listen carefully.
  5. Make mid-course corrections based on observation.
  6. Give credit.
  7. Communicate, communicate, communicate....


(We ran out of time, so there were no general questions at the end.)

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

Back to top

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


Good Enough Quality: Imperfectionism for Perfectionists


James Bach, Chief Engineer at Software Testing Laboratories, Inc.


I believe that the title is intentionally misleading. It gets your attention, as it is easy to mistakenly infer from the title that he is advocating mediocre quality, but what he is advocating is understanding and achieving appropriate quality. This level of quality can be achieved by understanding user expectations, and understanding the risk. This allows you to recognize when you are at the point where the benefits and the risks associated with a product are both at acceptable levels.


Software Testing Laboratories performs outsourced software testing. James is responsible for training the Test Leaders so that they can provide their clients with "good enough" software. He notes that the clients are happy with "good enough" because nobody wants absolute quality at all costs.

He briefly described some of his background, calling himself a pragmatist coming from the "market-driven software" industry. He spent time as a developer at Apple, where he wasn't happy because he was never satisfied with the quality of what he was developing. He then went into testing with an attitude of needing to get to zero defects (based on his readings of the literature). He also was often unsuccessfully looking for requirements documents and specifications, saying that he couldn't adequately test without them. These methods weren't very successful or popular. He had a difficult time reconciling what he saw as practices that should be leading to poor quality being performed at a successful company. A supervisor pulled him aside and pointed out that he needed to look at the other side of the equation: "What's the risk?" Quoting Gerald Weinberg:

"The quest for unbridled perfection is not mature, but infantile."

The talk was framed around "some fundamental questions about quality." By answering these questions, we can determine how to make the best use of limited time and resources:

  • What does "good" mean?
  • How de we recognize goodness?
  • Where does goodness come from?
  • What will we pay for more goodness?
  • When is more goodness bad?

Back to top

(He seemed to use "goodness" and "quality" interchangeably.)

What does good mean?

It depends on whom you ask. "Good" depends on who matters, and what they care about. The designer may describe the quality in terms of some innate elegance -- the aesthetic. The manufacturer can look at quality in terms of something meeting specification. Marketing normally thinks of quality as being related to people buying the thing. Finally, the customer gauge of quality could simply be "Does it solve more problems than it costs?"

This led him to what I see as the foundation of this talk. He described quality as:

The benefits of a product, minus the problems it has, as judged by its stakeholders.

This needs some definitions:

  • Stakeholder: Anyone whose opinion matters
  • Requirements: The desires of the stakeholders with regard to the product (can be implicit or explicit)
  • Problem: A violation of the requirements
  • Benefit: A fulfillment of the requirements

Back to top

He acknowledged that benefits and problems are somewhat hard to get your arms around, and pointed out that quality is an attribute of more than the product. It is affected by the interaction of the product, the people, and some system. For example, the apparent quality of a product with many bugs can be improved with lots of easy support. Products can also have multiple stakeholders with differing requirements. Finally, a benefit for one person can be a problem for someone else. He provided us with another quotation (I missed the attribution):

"There is no advantage that is so beneficial that somebody doesn't have a problem with it, and nothing so awful that someone isn't happy with it".

He described a situation where he was using a product -- some kind of time scheduler. It obviously had lots of bugs, and many people who saw him using it were appalled at its apparent poor quality. He was very happy with it because it worked, he needed it, and it did something that nothing else could do. From his perspective, the quality was good enough.

As often comes up in talks like this, someone brought up Microsoft, and some common perceptions of their quality. He reiterated his same point: He is satisfied that the Microsoft products that he uses provide more unique benefits than problems (again, the quality is good enough).

Another question: Isn't the Stakeholder just the person who's cutting the check? His response was that this isn't always the case, and there are moral, ethical, and legal issues at work here. If you have too short a focus, you can get burned. The person writing the check can very easily have a different agenda from other stakeholders (e.g., the end users). Testers need to have an understanding of who all the stakeholders are, and what each of their expectations are.

How do we recognize goodness?

He provided a list of nine quality elements:

  1. Capability
  2. Reliability
  3. Usability
  4. Compatibility
  5. Installability
  6. Efficiency
  7. Testability
  8. Maintainability
  9. Portability

The relationship between quality and some measurement of these elements is non-linear and contingent. It cannot be defined without using judgment; there are always trade-offs. He mentioned QFD as a possible mechanism for getting an organized and unbiased aggregate of quality factors, but he doesn't believe that it is generally effective. He knows of no technique that allows us to take different measures and aggregate them into a meaningful and reliable quality measure. Someone asked about doing a simple comparison of the same quality measure applied to two similar products. His answer was that he would be skeptical because you don't know whether one product is "worse" or if the metrics were defined or measured wrong. Even though there are problems trying to use these quality elements quantitatively, they can be used as powerful tools to drive the dialogue leading to good judgment.

One way to recognize goodness is to evaluate a product against its specification. He defined two types of specifications:

  • An explicit specification is formally acknowledged.
  • An implicit specification is not.

One is not more important than the other. At his company they teach the testers that a specification is any reference that is used to evaluate a product (user guides, messages, packaging, standards, common expectations, ...). His company uses a one-page sheet of some implicit specifications for any product (e.g., "a product should not unexpectedly cease to function"). These kinds of "requirements" often are not documented, so if someone uses only an explicit specification to drive testing, they can miss a lot -- and spend much time chasing things with little ROI. Also, practically speaking, his company often doesn't get any documented specifications so they have to rely on these other means to determine how a product is expected to function. He mentioned one product that came to them with nothing but a single Post-It note for documentation.

What are the sources of criteria for recognizing goodness?

He described a process in which the testers confer with the stakeholders, acquire and infer requirements, and explicitly reference all specifications (implicit and explicit).

Back to top

Addressing the limitations of testing, he described testing as a difficult process in which you have to:

  • Anticipate your users: data, skills, actions, expectations, and environment ...
  • Examine a product that is: invisible, volatile, sensitive, complex, and unfamiliar ...
  • Use a process that is: endless, ambiguous, negative,boring, and laborious ...
  • To find problems that are unthinkable.

In closing on this question, he said that there is no sure way to recognize goodness or quality, but we can use a diverse set of half-measures. Some examples are beta testing, automated testing, manual testing, and observation. Both qualitative and quantitative measures should be used.

When discussing Beta testing, he pointed out that Microsoft found only five percent of their defects by way of a fairly expensive Beta Test -- but it was a critical five percent!

{At this point he started going fairly quickly through the remaining slides}

Where does goodness come from? There are three factors:

  • Values (clarity about what is wanted)
  • Insight (knowledge of how the systems work)
  • Control (effective actions taken to control the systems)

Back to top

He then spoke about heroes. His definition:

"A hero is someone who, for the general good, takes initiative to solve ambiguous problems."

Heroics can't be planned for, or be forced -- but you can build an environment in which heroes can grow and thrive.

Goodness also can come from having skilled people who collaborateeffectively to solve problems. Having good process patterns alsohelps. He said that he stands for thoughtful process (as opposedto thoughtless process). (This point was elaborated on in the Q&A -- see below.)

What will we pay for more goodness?

"Good enough" means that the risk and the opportunity are each at acceptable levels (of course this has to involve a judgment). He defines risk as the likelihood and impact of a problem, and opportunity as the likelihood and impact of a benefit.

To sum up: What is it that we are trying to do?

We need to find "the level of good enough" -- which means that we need to understand what "good enough" is and why it is "good enough."

Back to top

QUESTIONS & ANSWERS (paraphrased):

Q: You mentioned not being against process, but being against thoughtless process. What about those people who say that they just want to be told what to do?

A: Excellent point! The process at least needs to be clear as to how we are going to ask people to use their intellect. Also, people often are in the situation in which they don't know why they are doing something, but they do know that they are struggling. They may just want someone to tell them what to do differently. If someone doesn't need or want to know why the process is the way it is, then it is OK. The danger is that people won't know what problem is being solved and won't recognize when they are doing something that is no longer useful.

Q: How much of this presentation would change if your life depended on the software being developed?

A: Not a thing. The suggestion (in the question) is that on life critical systems, one needs more process. This talk does not preclude this. The key is to be knowledgeable. Doing the calculation of risk versus opportunity points out when there is a need for more stringent process or higher quality.

Back to top

October 1996 Meeting Report
by Johanna Rothman (Rothman Consulting Group)


Real Process Improvement: Benefit and Risk (Is Process Improvement Really Worth It?)


Tim Lister (Atlantic Systems Guild)


Tim opened with an anecdote. In '69 or '70, Nixon gave two talks, one week apart. The first one was in California on the need to persevere on civil rights. One week later, he gave a talk at West Point about the need to persevere in Vietnam.

On the topic of process improvement, Tim is a zealot&emdash;-a converted smoker. He asks two main questions:

  1. Before we enact a process, do we know whether its outcome will be of the highest value? When he consults, something is out of kilter. Upper management thinks that if they get their process right, then the problem goes away. Lister worries that people get so caught up in the process they forget about the work.
  2. How do we tailor a standardized process to make it as effective as possible for a specific enactment? He used the example of lead, through some sort of tailoring, turning into gold.

Back to top

MAIN POINT 1 (getting a high value outcome):

A huge majority of organizations are obsessed with productivity and quality, but no one measures either of them! Atlantic Systems Guild gets a call. ASG asks:

Q: Where is your productivity today?
A: Low
Q: Where do you want it to be?
A: High

Example: Project fails (comes in late). Is this a productivity failure or an estimation failure? Quality depends on what you're building. We are not obsessed with product. We can't define the product, so we define the process.

Back to top

What is software here? What do you deliver? Part of what you deliver is people (core team to enhance the next release, support it, etc.). (In Tim's opinion, this is a joke, because the same organizations don't even consider product benefit.) Theproject that is better is the one that provided the most benefit, not the one with higher productivity.

Real-world example: A communications company developed a system enhancement. This enhancement cost $55,000 per phone call (based on how much this enhancement was used). Where was the benefit? The project had very high productivity, but provided virtually no benefit to the company.

Could it be that process improvement rewards less daring projects?

  • Are we going to safe projects?
  • Are we breeding for childlike behavior (neotony)? (Wouldn't it be great if every project came in on time? etc.)

Back to top

Not every project can come in on time. But, R&D always trumps Manufacturing. There is some ingredient of R&D in all great software projects. Software is a medium to R&D. You can make every decision perfectly and get blown out of the water by R&D.

(He went on here for a bit about how all the easy programs have already been written, by those of us who wrote code in the 70's and 80's).

The example he gave was that of some guy having a great idea in the 70's, of delivering documents to Europe in under a week. When the guy starts his company, it takes airmail three days to deliver a document to Europe. He guarantees one-day delivery. He dominates the market until the R&D breakthrough&emdash;-the fax machine. The fax machine delivers the document in essentially real time, so the need for his service goes down dramatically. He didn't do anything wrong; he got trumped by R&D.

Before we enact a process, do we know whether its outcome will be of the highest value? Tim says we are in the business of invention, not manufacturing. This is the business of systems analysis on the project.

In many companies, taking on scary projects is not rewarded.

MAIN POINT 2 (tailoring a standardized process to make it as effective as possible for a specific enactment):

"Here's the block of granite, just find the statue inside."

Could it be that tailoring the process means more to success than the creation of the standardized process? How do people tailor the process?

  • The gut.
  • It felt like that.
  • Rumor.
  • We've always done it that way.

Finding the strategy for the tactics. "Risk Management decriminalizes Risk"

  • Paul Rook. Risk Management is not risk minimization.
  • We need to court risks with some form of sensible risk management.

Back to top

Assuming that in five years, this will be standard project management--his acid test for risk:

Find a project well underway. Ask how people feel about the deadline.

  • Troops: Zero chance (which October?). The troops are always full of gloom and doom. The attitude is "I don't know what the deadline is, but it's wrong."
  • First Line Manager: Doesn't see how to make it.
  • Project Manager: "We might just pull this one off."
  • Next level up: "As far as I know it's on schedule."

Risk management needs vertical communication. Risk Management is a proactive methodical process for:

  • Risk identification--Any variable out of your control that can acquire an unpleasant or unacceptable value.
  • Risk evaluation--"Do I want to manage this risk?"
  • Risk problem detection--"How do I know this will happen to me?"
  • Risk mitigation--Plan a reaction to the problem.

Back to top

Successful software projects are either on time or late. If you look at the on-time projects, you usually find that they jettisoned functionality. Why do we have no early projects??

Every project is planned as if there were no problems (planned for the earliest possible date). No project ever runs to plan.

Example: There are two 10-month projects. One team gets a ticker-tape parade, the others lose their bonus. The reason? The first project was ahead of schedule by two months, the second project was late by two months. Why punish (or reward) a team for an incorrectly estimated schedule?

Companies that say "We don't know what we're building" appear to be healthier than other companies.

Denver airport was not a software problem. It was a management problem, one of risk denial.

  • Baggage handling was not on the critical path (How could that be? What gets on and off a plane aside from people? Baggage!)
  • There was no risk management for baggage handling (Why not? Why did the project manager assume everything would go according to plan?)

Back to top

In lots of organizations, if you mention a risk, you own it.

How-to's of Risk Management:

  1. Create a census of risks.
  2. Assess probability and effects of each risk.
  3. Identify early expected symptom of each risk.
  4. Estimate cost of monitoring for risk.
  5. Determine which risks will be managed. For each one, do 6 &
  6. Agree on mitigation plans before the first symptoms appear (tripwire).
  7. Monitor continually for symptoms (does monitor cost more than the benefit?).
  8. Keep the process going.

Software process makes us look at what is common from project to project.

People are good at describing symptoms, not root causes. People think deadline is the problem. But the problems could be complexity or size--completely different frameworks are needed.

Back to top

An example from a real company:

Item - Risk # 27
Risk factor - May have to write bridge code to old code systems if all is not ready by 4/1/96.
Extent - 750 function points
Probability - 20%
Cost Impact - $150,000
Schedule Impact - Increase 10 weeks
First Indication - Not all designs pass detailed design review by12/20/95.
Weighted Impact = (Probability) x (Cost Impact for the time)

Risk inflates budget and schedule. For each milestone, there is an additional amount of time built in, to account for risk.

QUESTIONS & ANSWERS (paraphrased):

Q:Can the tripwire not affect your schedule?

A: The tripwire itself allows you to see that you cannot make your schedule, due to risk.

Q: Are all dependencies risks?

A: Lister doesn't treat them as risks unless they are outside the control of the organization. However, you do need to write down all the assumptions. if what you plan isn't' true, then all bets are off. Once you've been doing risk management for a couple of years, look for patterns. Are there organization-wide problems?

Reporter's note: I was unable to capture Tim's intensity and humor in this meeting report. The next time "the guy with the big hair" comes to talk, you should plan on attending!

Back to top

December 1996 Meeting Report
by Johanna Rothman (Rothman Consulting Group)


5-Minute Madness


John Howland, EMC Corp.


John Howland, of EMC Corp., was the moderator for a free-wheeling evening of five-minute madness. John started things off discussing the NASA conference that Vic Basili puts on every year the Wednesday and Thursday after Thanksgiving. He regaled us with visions of Chesapeake Bay shellfish and Big Names in the software engineering field coming together for two days of intense workshops. If you're interested in the conference, see the web site

Someone asked about the form of software engineering organizations. The problem under consideration is how do you best organize so that the people working on the projects all know what's going on, and so that people in specific functions can continue to improve their skills, and so that the process improvement people are not working in a vacuum, and continue to improve their skills. JR's experience is that a project-based organization works best for the projects, but is difficult for improving specific skills, such as improving testing abilities. One way to improve specific skills is to have the functional group manager mentor the projects--both the people in the function as well as the project leaders. A fellow from Boeing said that they used people from the process improvement group on projects (sort of a temporary transfer) to keep up their skills. Another person said that they had maintained an unworkable functional organization through a number of reorgs, and that the organization worked only through the personality of the people in the organization.

Dale Emery and Judy Bamberger gave a joint presentation about undiscussable issues. They had just come back from a consulting assignment in the Netherlands. The assignment was to facilitate a three-day meeting held to define a schedule for a multi-continent (US/Dutch) project. Dale and Judy found that while they were there to facilitate a project schedule, what they really did was act as catalysts for these undiscussable issues. People came up to them separately and said "How come we're not talking about 'x'?" Dale and Judy touched base with each other during the first day, when it became obvious that this was happening a lot.

The undiscussable issues were:

  1. Trust: Management vs. developer, promises (especially of bonuses) not kept, "inhumane" working conditions.
  2. Communication: I send email and get no response. Is that about me? Is the other person too busy? Are our priorities different?
  3. Why merge with a company that is so far away (nine-hour time difference, 24 hours travel time) when we don't want to?

Back to top

Dale and Judy brought these issues to the overall project manager, who understood he had work to do. This was the first time he'd heard directly about the trust issue. Originally, he had expected to an organizational climate survey at the end of the meeting, but decided it was irrelevant now.

Dale and Judy helped facilitate discussion among the groups about the three issues while trying to get to the specific tasks. The final event of the meeting was to present the outcome to the CEO. Everyone thought the CEO wanted a project completion date, and there was substantial pressure on the leaders to come up with a date. However, because the whole task force had not worked out the issues--especially trust--the task force did not present a date. The task force leadership realized that if they chose a date, they would lose the trust they had spent the last three days building.

John Howland's first reaction to this was that there was a "lack of radical honesty." He asked what kind of organization was this? Dale and Judy answered that the Dutch perceived the Americans as cowboys, and the Americans perceived the Dutch as bureaucrats. In the end, the task force used consensus for decision making. The management team empowered the individual project teams at the beginning of the meeting. The individual project teams started rumbling about pre-ordained outcomes. (This was an instance of the lack of trust.)

Someone else asked why not use a project scheduling tool? D&J said a tool was being used, but if you don't know all the dependencies, the tool still can't give you the right answer. The point of the meeting was to identify the unknowns, identify the tasks, and generate a list of risks and uncertainties.

There was some discussion about comfort with the estimates. None of the estimates were based on hard historical data, just gut feel. The gut feel part made D&J nervous. D&J are thinking about how to articulate the nervousness into somethng the project people can understand.

Judy had an anecdote about going to dinner with the CEO, who is a smoker. Judy can't tolerate cigarette smoke, but she felt that this issue was not entirely discussable. She explained this as a rule for commenting. (When you're young you're told "If you can't say something nice, don't say anything at all.") However, as she thought about it, she decided that she needed to say something in order to enjoy the dinner and to be congruent with her handling of the issues of trust.

Someone asked wasn't this more a question of self-esteem rather than an undiscussable issue? Judy said yes, but there are imagined threats when you tell the person with the purse strings something you are sure he/she is not going to like.

Back to top

Tom Janzen then gave a short presentation about the state of software process in the Help Wanted section of the Boston Globe. A summary of this is on Tom's web page: The quick version is that Tom counted 37 pages containing 1053 ads on 11/24/96. He then used the following rules to describe the ads statistically:

  • He counted ads, not positions.
  • Degrees were not distinguished by type.
  • "Process" count was somewhat objective.
  • He counted only development positions, not support.

Of all the ads, 5.6% were software. Of those ads, 8% mentioned something that might be related to process. Two ads mentioned ISO 9000. There were no other buzzwords. 31% aasked for degrees, 42% mentioned C++, 58% did not mention C++.

Tom's conclusions from the statistics:

  1. Companies forget to mention process in their ads.
  2. Only one in seven companies know about process.

Tom's plans for himself:

  • Remove all allusions to process in his resume.
  • Get an MSCS.
  • Stop attending SPIN (due to his class schedule).

Back to top

After we all stopped giggling, Tom added the following comments:

  • Companies really don't do process work.
  • Companies don't want to scare applicants. (Some developers think process is a plot designed to keep them from doing what they like best--writing code.)
  • Companies are interested in people who can solve problems (that is the problems of today, not the root causes of the problems).
  • Companies think process is a dirty word.
  • One in seven organizations may know they have a process.
  • Process comes from within.
  • We, as process people, may be too caught up in ISO and the CMM structure. We've lost effectiveness measures. Are we providing effective change, effective empowerment?
  • Process improvement is not seen as a profession. We need to recognize culture and development, etc., to know how to solve problems.
  • Is this a geographic thing, limited to the Northeast?
  • Is this a cultural thing--quality vs. test vs. process?

A number of folks had comments for Tom.

Paul Newcum said:

  • Focus on people. Don't talk about process, talk instead about staff burnout, defect reduction, schedule control.
  • Take away jargon, and translate it to something that means something to management.
  • Estimate a module's work in toto (code, disinfect, document, test). Then you have a mechanism to discuss.

Back to top

Dale Emery said that he focuses on the Cost of Quality:

  • Am I doing this for a customer (external non-conformance)?
  • Am I doing this task for an internally found problem (internalnon-conformance)?
  • Am I appraising a product?
  • Am I preventing defects?

Phil Glaser said that long-term payoffs reap the benefit of short-term investment. We work in a volatile industry. He gave the example of an organization which plans for 100% turnover every two years. They look for short-term gains. This causes problems--They don't want to be the cause of something that costs a lot of $$.

John Howland gave the example of inspections, and said that the greatest barrier to inspections are guilt and shame. He got around that by telling the CEO that they saved $1K per bug found in an inspection. "I saved you $15,000 today." After telling the CEO this every day for a few months, the CEO came to him, and said "How much did you save me today?" John connected what they were doing with the needs of the business. He doesn't talk about the "p word" (process), but about how to connect the improvement program to the business program.

The gentleman from Boeing gave some interesting examples: Bugs have more and more visibility. We all probably believe a bug in the operations of an airplane is more important than a problem showing the in-flight movie. However, for many people visible bugs are as important as possibly invisible but fatal bugs, because they see them as linked: If you're on an airplane and the tray table is dirty, you are more likely to wonder whether the engines will work.

There were other comments:

Employees show no loyalty. Companies show no loyalty. How to make this work in the face of no loyalty.

Someone commented that they count defects in reviews not as major or minor, but as operational or non-operational.

Kudos to John Howland for once again starting off the meeting and keeping things moving.

Back to top


EDS (Electronic Data Systems) NH Title XIX account is a progressive organization in the process of improving our software capability maturity as we pursue new development opportunities and increase the value of the services we already provide for our customer. We are looking for self-motivated and experienced Systems Engineers with a combination of the following skills:

  • Software process & methodology experience
  • Demonstrated ability to provide technical expertise and leadership
  • At least two years of project experience using ^QC^R, LBMS or COBOL
  • SQL and/or UNIX experience desired
  • Healthcare industry experience a plus

EDS has openings on both a permanent and a temporary basis. For consideration, please fax your resume to the EDS Systems Manager at (603)225-7964 or email to For additional information, please call Scott Workman at (603) 225-4899 X3040.



411 Massachusetts Ave., Suite 103, Acton, MA 01720
tel: (508) 263-7899 fax: (508) 263-5422

Back to top


CONTACT: Bill Shaw or Nancy Hopkins

Please Note:

The following client companies are staffed with proven management talent (true "team" builders), are securely funded (not hesitant to pay "top-dollar" for "top-talent"), offer the opportunity to work with "cutting-edge" technology, and include equity.


Boston Area: Multiple positions for individuals who have experience in test scripts, test plans and bug tracking systems. Will establish test cycles and use automated test tools.

Specific Skills: UNIX or Windows, C++ and JAVA.


Cambridge: Senior Software Quality Professional to test company products designed for use on the Internet.

Specific Skills: A combination of skills in UNIX, Win '95, NT, Informix, Oracle, UI, test automation.


Rt.495 Area: Senior position testing software in the Windows NT, or Windows client/server applications in a Windows/Windows NT environment. Experience writing automated tests.

Specific Skills: Windows/Windows NT, GUI testing, knowledge of DB concepts, working knowledge of C/C++


Back to top

Rt. 495 Area: (Multiple Openings) Senior and Junior QA Engineers to participate in design reviews, project plans and schedules and the moderation of code inspections.

Specific Skills: Experience developing products, test scripts or tools in a structured environment. C/C++ required. Distributed computing or client/server experience and/or Win NT/Win'95 system software testing background is desirable.


Rt. 495 Area:(Multiple Openings) Develop and execute plans for testing the next generation in advanced storage management technology for Novell NetWare and Windows NT-based client/server networks.

Specific Skills: Experience in at least one of the operating systems: Windows '95, Windows NT, NetWare 3.x, NetWare 4.x, automated software testing or software development experience, knowledge of QA methodologies and procedures.

Optional Skills: Network communications protocols, including Internet, IPX, and IP, QA Partner and/or Visual Test , or C/C++.


Rt. 495 Area: Director of Quality Assurance: Build-on to an existing QA staff ; implement quality methodologies in partnership with software development. This is a highly-visible position within the company as well as within the international client/server industry!

Specific Skills: Proven leadership/management record, current technical knowledge (platform is Win NT, Win '95), ability to succeed in fast-paced, start-up environment.

Back to top




As a member of the Software Group you will work within a dynamic team environment to develop software applications such as our award winning TextBridge and newly released Pagis family of Optical Character Recognition (OCR) products. Continued advances in document recognition, image capture and document management have created application development opportunities for motivated individuals committed to delivering winning products to the software marketplace.


Hands-on manager to lead technical team in planning, development, implementation and maintenance of internal network and systems support technology for our multi-platform software development organization. Prior technical staff management and strong knowledge of UNIX platforms/environments, Novel Netware, LAN/WAN development and RDBMS are required. Pluses would be familiarity with TCP/IP, ISDN, FastEthernet, and MRP systems. BS in technical discipline, related degree or equivalent experience req'd. Technical MS or MBA is a plus. Job code: MIT


Develop and conduct test procedures to insure competitive performance and reliability of our scanning and OCR software applications in Windows and MAC environments. Strong testing methodology, automated and manual test experience are required. Plus skills are Windows NT, Windows 95, SQA Robot and QA Partner. BSCS, related degree or relevant experience req'd. Job Code: SQA



Responsible for managing product delivery process from concept development to successful product market launch. Will lead efforts of internal development, quality assurance and marketing resources and external partners and vendors. Requires relevant product management experience with key involvement in 2-3 prior successful product launches. Proven experience in establishing successful relationships with external partners a big plus. BS in engineering, marketing or equivalent required. MBA a plus.

Job Code: APM


Seeking an Electrical Engineer, with experience in analog and digital design, to function as a member of our Adaptive Technologies' design team. Primary duties include engineering cost reductions, improving manufacturability and insuring agency certification (i.e. FCC, FDA, UL, TUV , VDE). Responsibilities also include vendor negotiations, interfacing with production line management on all technical and procedural issues, defect analysis and recommendation of product fixes. Requires occasional travel to production and vendor facilities within North America. BSEE or relevant degree and experience also required.

Job Code: EEP

Xerox DDS offers a highly competitive salary, an excellent benefit package and a drug-free work environment. TO APPLY, send resume to:

9 Centennial Drive, Peabody, MA 01960
Fax: (508) 977-2129 E-mail:
No phone calls please. An equal opportunity employer, M/F/D/V

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 sponsors, GTE and Raytheon. We also thank U/Mass at Lowell for hosting our WEB page, and Digital Equipment Corporation for Ed Maher's SPIN Meeting Reports.

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:
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 or bimopnthly September to June. Letters, notices (including job postings), and contributed articles are welcomed. Articles do not necessarily represent the opinions of anyone besides their authors. We do not publish advertisements or job searches, but we will gladly publish job postings.

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

Return to Newsletter Index

Back to top