TwinSPIN Newsletter: Volume 1, Issue 2
December 1, 1999
CONTENTS:
* Editor’s Note
* Writer's Guidelines
* TwinSPIN December Meeting
* "What's the Real Problem?" by Johanna Rothman
* "Requirements Management" by Gordon Dosher
* Web Picks by Esther Derby
* "How to Rapidly Change Your Organization using FAST" by Timothy G.
Olson
* Announcements & Calendar
* About TwinSPIN
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Editor’s Note
Since we have a long newsletter this month, I'll keep this short and
sweet. Thank you to Gordon Dosher and Tim Olson from TwinSPIN for
contributing to this month's newsletter. Thank you to Johanna Rothman of
the Boston SPIN for allowing us to reprint her work. And thank you again
to Esther Derby for Web Picks, for Writer's Guidelines, and for making
arrangements with Johanna Rothman.
P.S. We are still looking for names for this newsletter - any
suggestions?
Send letters-to-the-editor, comments, questions, submissions, or
anything else relevant to Pat Wegerson at weger002@tc.umn.edu or at
612-448-1335.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Writers Guidelines
The goal of the TwinSPIN Newsletter is to provide articles and
information with a real-world perspective that will be useful to you,
the readers. And who could know more about real-world software process
improvement than the members of a SPIN? If you've ever had the urge to
be an author and have an insight you'd like to share, consider writing
an article for the Newsletter!
In general, articles should be fairly short, not more than 1000 words
(since the Newsletter is distributed electronically, we can't
accommodate graphs and figures at this time). We're looking for
articles with a "how-to" bias, and we also like to put a lighter piece
in each issue. Articles that are academic or commercial are less likely
to be of interest.
If you have an interest in writing an article or contributing one that
has been previously published, please contact Pat Wegerson at
weger002@tc.umn.edu or at 612-448-1335.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TwinSPIN December Meeting
Topic: Improvement Model for Small Organizations
Speakers: Arvind Ganesan and Mike Breckenridge
When: Thursday, December 2, 1999 from 6-8 P.M.
Where: University of MN, Electrical Eng/Computer Science Hall, Room
EE/Csi 2-260 (Minneapolis, MN)
Sponsor: Metaphase, Cynthia White
Program Director: Jesse Freese
Meeting Directions
==================
Please check out the maps (see below) or contact Jesse Freese
(612-882-0800 or Jesse_Freese@Fissure.com) if you need additional
directions.
For maps:
1. Browse to http://www1.umn.edu/tc/maps/EECSci/
2. Touch "Close up view" below map for more detail.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
What's the Real Problem?
Copyright (c) 1999 Johanna Rothman
The Product Development VP said "Reduce development costs by one-third
in the next fiscal year. You two make it happen". Sally, the Director of
Engineering and Tom, the Director of Quality looked at each other. They
thought "How the heck can we do that?" and "We know what costs we're
supposed to reduce: us!"
When we hear directives from our senior managers, we have all kinds of
reactions, many of them resigned or cynical. Directives give you some
insight to the problem and are a place to start defining the
requirements to solve a problem. Directives are not real problem
statements. When you get a directive, take time to define the problem to
solve, the real business results you want to achieve.
First, avoid thinking you must obey the stated directive. Ask some
questions first, such as:
"Oh, it sound like you're concerned about costs"
Once you have agreement about and understand your manager's concerns,
ask context-free questions to define the real problem. Context-free
questions might be:
Who are the clients of this activity?
What does a highly successful solution look like?
What is that solution worth to you?
Why are these results desirable?
One of my clients was convinced they had to reduce product development
time from 12 months to 6 months. I was concerned about their ability to
reduce cycle time, so I asked some questions of a senior manager (SM):
SM: We want to reduce cycle time.
JR: Why?
SM: Well, we want to get our products to market faster, so we can
improve our return on our product development investment.
JR: What return are you currently getting, and what return do you
want?
We discussed the total costs of development and support from some
previous releases and came up with a specific desired business result:
Reduce cycle time in order to see sales impact from major releases in
less than 6 months.
This organization's customers typically waited about 12 months after a
release to buy the new product. This is not a problem of just cycle
time. Cycle time reduction was part of the solution, but not the only
solution.
We proceeded with our conversation:
JR: What is the reduction in cycle time worth to you?
SM: A lot.
JR: What does "a lot" mean to you? Is it worth a $3,000,000
investment in equipment, training, and process improvement? Is it worth
more or less than that? Is it worth some of your time?
In order to frame a real solution, I had to understand the SM's
tradeoffs.
JR: what does a successful solution look like to you? Can you
describe what the solution looks like or feels like to you, to your
managers, to your technical staff?
SM: Well, everyone's busy working on the new release, doing their
work, not wasting time.
I didn't think people were wasting time, so I asked a slightly different
question:
JR: Let's assume people aren't wasting time now. Does the mix of work
change? Do other groups change how they work? Do you work differently?
Do you have different problems than you have now?
The Senior Manager then realized what I was asking for, and answered me.
Then we talked about why these results were desirable:
JR: Why are these results desirable? Aside from a reduction in cycle
time, what else do you get from this work?
By the end of this 1-hour conversation, I had the information I needed
to be able to start framing the real problem, and some of the
requirements for the solution. Even better, the senior manager realized
that just issuing a directive wasn't enough to get to the needed
solution.
Instead of turning into cynics or becoming crazed when you hear a
directive, calmly develop a problem statement and then figure out what
you need to do to solve the problem.
To learn more about context-free questions, see Gause and Weinberg's
Exploring Requirements, Quality Before Design, published by Dorset House
Publishing, New York, 1989.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Requirements Management
By Gordon Dosher
Recent industry metrics indicate that the most common cause of project
failure is poor requirements management. Failed projects are those that
are at least 5% over cost or 50% over schedule, or lost at least 50% of
planned functionality. Thirteen percent of failed projects reported
requirement management problems as the main cause. The next most
frequent cause was lack of user involvement in the development, which is
also a requirements issue.
Poor requirements management can crop up at any stage of product
development.
* The product idea may not meet market desires.
* Requirements development may not include important stakeholders and
result in incomplete requirements.
* Requirements may be poorly communicated to those who use them.
* Designers may not implement requirements correctly or may make
design changes that violate requirements. Such changes may not be
communicated to those who need to know.
* Test activities may fail to verify or validate some requirements.
The underlying cause of poor requirements management at any stage is
usually impatience. We want to get our idea to market quickly. We do not
want the overhead of managing requirements. We may view function and
performance as the only important requirements.
Effective requirements management has five elements:
* Eliciting requirements
* Synthesizing requirements
* Communicating requirements
* Validating requirements
* Managing requirements changes
Eliciting requirements is more than just talking to customers, although
that is an important aspect. Most requirements do not come directly from
customers. A customer may not tell you that a product needs to be so
fast or such a size or have this kind of user interface. The customers
will say that their systems are too slow or that hardware takes up too
much floor space or that controls are hard to understand. The people
asking for customer input must know what to ask for. Those solicitors
have to be able to ask for clarification. They have to be able to
translate customer input into a set of product attributes and then get
affirmation from the customers.
In addition to customer input, we have other sources of requirements.
Our competitors will be pushing the bar higher and cost lower. We have
to comply with regulations from the government and other bodies. We have
organizational standards. We must consider all of these inputs when we
develop a set of requirements.
A list of requirements must be synthesized into product attributes. If
process cycle time is a requirement, the parts of the product that do
that processing had better be that fast. If a corporate color scheme is
important, you must specify what standard shade to use, not just say
"purple." Synthesis is critical, because it ties the requirements to a
design concept. It also accounts for the way you do business. If your
design methodology is object-oriented, you will probably specify
requirements differently than if you use structured design.
Synthesis segues nicely into communication. There are two important
things to remember about communicating requirements:
* Know your audience (who uses the requirements)
* Know your audience (how they use the requirements)
I recently audited our software development groups. Out of the many
people I talked to, only one knew that our test group used the software
specifications to develop test plans and test cases. I have also seen
many cases where designers could not understand the requirements or
interpreted them incorrectly. Good requirements writing is beyond the
scope of this article. One good practice, though, is to learn from your
mistakes. If someone misinterprets a requirement, find out why and learn
to communicate the requirement more clearly in the future.
The validation stage of development also has requirements pitfalls.
Problems caused in synthesis and communications are present, plus some
others. Test coverage is important. You want to make sure that all
requirements are verified and validated. A requirements tracking tool is
helpful. It is a map from each of the requirements to every place they
are tested. It can be as simple as a matrix on paper or it can be
embedded in a requirements management tool. You not only need to test
for the nominal cases (go paths), but also the fault cases (no-go paths)
as well. Customers will find the paths you do not test.
Requirements change management spans all stages of product development.
It is just as critical as the other aspects of requirements management.
There are few things more frustrating than finding out that someone
else's subsystem no longer meets the interface requirements to which you
were designing. Test people often complain that they developed tests for
requirements that are no longer valid. Change control boards are
critical. For small organizations, change boards can be informal, as
long as people understand the rule--tell everyone about your changes.
Larger organizations need formal change boards and defined change
communications. There must be agreement on how to negotiate changes and
who has decision-making authority. An hour a week on change control can
save person-weeks of rework due to uncommunicated changes.
Requirements management will give most organizations the biggest
bang-for-the-buck. It embodies the theory that the earlier you can
prevent problems, the more time and money you will save. Good
requirements management methods more than pay for themselves in saved
schedule time and development cost. People are actually happier in such
environments than always having to fight requirements.
Copyright (c) 1999 Gordon Dosher
GORDON DOSHER is the Quality Manager at the Storage Networking Business
Group of StorageTek, a leader in enterprise tape and disk storage
products. He has been with StorageTek for 4 years. Gordon is responsible
for maintaining the quality system of the business group. In addition,
he manages the product development process for the group. He
occasionally manages programs and tries to practice what he preaches.
Prior to StorageTek, Gordon worked at Honeywell and its spin-off,
Alliant Techsystems for 17 years. While there, he did electronics
design, systems engineering, engineering management, and project
management. He has a B.S. in Engineering from Colorado State University
and a MBA from the University of St. Thomas.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Web Picks
by Esther Derby
I once heard the Internet described as being like a library, except the
card catalog has been dumped over on the floor and mixed around;
there's lots of interesting material, but there's no systematic way to
find it. And that's why I like links pages. When I find a good links
page, it saves me from sifting through all the cards and wandering
through site after site looking for what
I need.
STQE.net is an on-line resource for testers, developers, and QA
professionals. It's organized into 7 areas: Software Testing,
Requirements, Configuration Management, Metrics, Project Management,
Quality Engineering. and Reviews/Inspections. Each section has a forum,
a "library" and links. The "library" and links sections are annotated
-- they contain a short description of the material referenced. The
ones I've checked have been accurately described and provide value.
Which means that I can pick my topic and use the annotations to help me
determine which sites are useful to my current focus and which sites I
can save for a day when I have time and inclination to wander. (While
STQE.net does have commercial sponsors, the links and library do not
appear to be chosen to favor those sponsors.)
Copyright (c) Esther Derby 1999 derby@estherderby.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
How to Rapidly Change Your Organization using FAST
By Timothy G. Olson
Forward
The following paper was presented at a panel on managing change at SEPG
'97 in San Jose, CA. It is a parody of 10 things NOT to do when managing
organizational change, written to humorously highlight some common
pitfalls.
A FAST Introduction
This paper describes an overly successful method for rapidly changing
your organization called the FAST Change Method. Many organizations
that have stayed at SEI CMM Level 1 for years have proven that the FAST
approach really works. All of the examples in this paper are true, but
the names have been changed to protect the guilty.
The FAST Change Method
Well, it's finally here. The silver bullet that you all have been
waiting for has arrived. It's called the FAST Change Method. FAST
stands for:
* Fake
* Action
* Speeds-up
* Transition
Sounds too good to be true? I know it's hard to believe, but it works!
Politicians have been using it for years. Now you can use it too!
Guaranteed FAST Pace Change
If you want to make FAST changes in your organization:
1. Don't waste your time getting top management buy-in (they don't know
what's going on anyway)
2. Contract out quality (face it, you don't know how to do it)
3. Don't manage those "soft" mushy people issues (play corporate
"hardball" politics instead)
4. Use complex change models to confuse your audience
5. Keep people off balance by introducing many changes all at once
6. Introduce major changes that go against the culture of the
organization
7. Don't ever practice what you preach (this requires way too much work)
8. Only promise change (never promise improvement)
9. Make frequent promises of change (and then break them)
10. Hire a Ph.D. in statistics to fake your measurement program
1. Working FAST With Top Management
Remember, getting top management buy-in is a waste of time. There is
only one principle you need to know about senior management, and that is
TCRA (They Can't Remember Anything). Just approach senior management to
sign an approval letter and tell them they have already approved the
idea a couple of months ago (or just forge the letter because they won't
remember signing it anyway).
2. Contract Out Quality, FAST
Face it, worrying about quality is a pain. The FAST Change Method has
you contract out your quality... to us! You don't have to worry about
your quality, and we make lots of money... FAST.
3. Make People Jump FAST
The secret to rapid change is to realize that people are afraid to lose
their jobs. This is why we can call people "change targets".
Therefore, the best way to deal with people is to drive in fear and tell
them to get back to work.
4. Use Complex Change Models FAST
People are generally afraid to ask stupid questions. So present
extremely complex change models and pretend they are simple and obvious
to the casual pre-schooler. If someone does ask a question, either say
"boy, that's a stupid question", or just ramble on about something
irrelevant until they forget their question.
5. Introduce Many Changes all at Once FAST
Organizations take way too long to change. This is why you need the
FAST Change Method. Because change takes so long, FAST introduces as
much change as possible all at once. For example, FAST has a web page
that uses a random number generator to help you to perform a quick
"reorg". Remember, the more change the better.
6. Introduce Changes Against the Culture FAST
Organizational culture is just a fancy word for "politics". When you
hear about "resistance" to change, tell them you have your best people
working on it (it's an electrical engineers job to work on resistance).
The best way to change an organization is to introduce a fake change to
politically distract everyone while the real change is quietly slipped
in. This is how taxes are raised.
7. Don't Ever Practice What You Preach
You may have heard the following old sayings: "practice what you preach"
or "walk the talk". These are noble statements, but the FAST Change
Method has no time for this. Always remember this helpful guidance:
* Everyone else needs to improve, and you don't.
8. Only Promise Change
Remember that improvement is very difficult. Change is easy. The FAST
Change Method guarantees rapid change by ignoring improvement. You may
have heard the old saying, "no pain, no gain". The FAST method
leverages this principle by taking away your pain, and passing on to
others (now you know why they call the other people "change targets").
9. Make FAST Promises
The secret to any rapid change is to the appearance of the change.
Image is everything. Hire a professional marketing organization and
improve your image. Use a marketing survey to ask people what they
want, promise them everything, and then deliver nothing. Politicians
have been doing it for years with no consequences.
10. Hire a Ph.D. in Statistics, FAST
The FAST method is so rapid that it doesn't have time for real
measurements. The best way to bluff your way past management is to hire
a Ph.D. in statistics (the FAST Consulting Organization will provide you
one for a large up front fee). Nobody argues with a Ph.D. in statistics
no matter how insane the data may appear.
A FAST Summary
Face it, your management wants a silver bullet. So give them what they
want, FAST! You can also purchase "FAST Lite"; everything you ever
wanted in a change method, and less!
Copyright (c) 1996 by Timothy G. Olson
TIMOTHY G. OLSON is Founder and President of World-Class Quality (WCQ)
and Quality Improvement Consultants (QIC), Inc. Mr. Olson is a Juran
Institute Associate, an Authorized SEI Lead Assessor, and was also
employed at the Software Engineering Institute (SEI) for almost 7 years
in the Software Process Program. Mr. Olson is an adjunct professor at
the University of Minnesota, is a member of IEEE and ASQC, and he helped
start-up two SPIN's in the Twin Cities, Minnesota area. He can be
reached at:
Quality Improvement Consultants (QIC), Inc.
3082 Hamline Avenue North
St. Paul, MN 55113
(651) 636-2234
Tim.Olson@worldnet.att.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Announcements & Calendar
Recent and upcoming SPIN meetings:
Format: *SPIN name (contact information), Date, Topic, Presenter
(presenter's organization)
*Albuquerque (http://www.abqspin.org/), 11/14-17/99, High Integrity
Software Conference, Sandia National Laboratory
*Association for Software Engineering Excellence - ASEE, Dallas, TX
(http://LoneStar.rcclub.org/ASEE/), 12/7/99, TBD,
*Atlanta (http://www.cc.gatech.edu/SPIN/), 11/16/99, Business
Rules-Based Architecture: Finding & Coding the Rules, David Wendelken
(Stonebridge Technologies)
*Austin (http://www.utexas.edu/coe/sqi/groups/improve.html), 1/20/2000,
Clone Detector Toolset, Ira Baxter (Semantic Designs)
* Bay Area Round Table - BART (http://www.ics.uci.edu/IRUS/), 11/12/99,
Y2K: Start the Party or Sound the Dirge?, Tony Wasserman (Software
Methods & Tools)
*Boston (http://www.cs.uml.edu/Boston-SPIN), 11/16/99, Good Enough
Quality, James Bach (Satisfice, Inc.)
*Chicago (http://www.prairienet.org/cspin/), 11/4/99, (Panel Topic) An
Executive Panel on Recruiting, Retention and Organizational Questions,
Moderator: Peter Wilson (Mosaic, Inc.)
*Los Angeles (http://sunset.usc.edu/las/index.html), 12/1/99, Process
Asset Library & Process Automation, Dr. Ray Madachy & Dr. Denton Tarbet
*New York CitySPIN (http://www.nycspin.org/main.html), 12/7/99, TBD
*Northeast Ohio, 10/6/99, What do we need to know? The Software
Engineering Body of Knowledge, Jack Bar-Ness (Picker International)
*Omaha (http://www.omahaspin.org/), 12/2/99, Capability Maturity Model
Integrated, Bob Rassa (CMMI Steering Committee)
*Philadelphia (http://www.eptech.com/quality/spin/SPIN.html), 1/19/2000,
A Hybrid Approach to Achieving Level 5, Bill Pitterman (Telcordia
Technologies)
*Phoenix SPIN/IEEE-CS/ACM (larue.miller@bull.com), 11/16/99, A Process
Being Used to Generate Reliable Software Estimates, Ron Paul (IIS)
*Pittsburgh, 12/8/99, Beyond the Hype, a Realistic Look at XML, Charlie
Beard (Westinghouse Electric)
*Research Triangle Park NC, 10/28/99, Using the ICED T Model to Test
Subjective Software Qualities, Andy Roth (Rational)
*Rochester NY (http://www.rsqu.org), 11/11/99, Do You Believe in
Fairies? What about Software Process Improvement?, Jack Hill (The
Navigation Group)
*San Antonio (http://www.saspin.org/), 1/12/2000, Testing TBD, Dr. Magdy
Hanna (Software Dimensions)
*Silicon Valley, 11/17/99, A Discussion on Learning, Charles Fitzgerald
& Gregory Scott
*Southern California (http://www.ics.uci.edu/IRUS/), 12/3/99, (Panel
Topic) The Effect of Corporate Mergers and Teaming on CMM-Based
Cultures: Will this Takeover Impact our CMM Level?, Coordinator: George
W. O'Mary (Boeing)
*Toronto (http://www.interlog.com/~torspin/), 11/4/99, Process that
Works: liberating software Processes & Developing Web Applications,
Gerry de Koning & Robert Fabian
*Twin Cities Quality Assurance Association - TCQAA
(http://www.tcqaa.org), 12/9/99, Integrating Quality into Project
Management, Curt Highet, Blue Cross / Blue Shield of MN
*Washington D.C. SPIN (http://www.software.org/dcspin), 12/8/99, When
the project positively, absolutely must get done: Marrying the
organization chart with the PERT diagram, Stan Rifkin (Master Systems,
Inc.)
*Washington, D.C. SSQ, 11/9/99, National Software Quality Experiment: A
Lesson In Measurement: 1992-1997, Don O'Neill
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
About TwinSPIN
============================================================================
For the Minneapolis/St. Paul Regional Area
TwinSPIN Mission Statement
--------------------------------------------------------------------------------
The TwinSPIN software process improvement network (SPIN) is a regional
organization established in January of 1996 as a forum for the free and
open exchange of software process improvement experiences and ideas.
Representatives from industry, government, academia, other professional
organizations, and consultants are welcome to participate. Our mission
is to help sustain commitment and enhance skills in the area of software
process improvement through an active program of networking and mutual
support. The organization strives to serve as a source of educational
and experiential information for its members, other SPIN organizations,
and the general community of software professionals. (May 1996)
--------------------------------------------------------------------------------
Meetings are normally held on the 1st Thursday of each month from 6-8
PM.
TwinSPIN is a non-profit organization.
============================================================================
TwinSPIN web site: http://www.homepage2.rconnect.com/glewwe/TwinSPIN/
All articles, reviews and commentaries are copyright by the authors,
unless otherwise noted. All rights are reserved to the authors. We
encourage sharing the TwinSPIN Newsletter in whole or in part if
copyright and attribution are always included.
