Our Business is Change
by Pat Craig
from the Summer 2001 issue
of the Complexity Management Chronicles
"Our business is change. Our job isn't done until
the job is done. Beware of energy takers versus energy givers. Assume nothing.
We're on offense - All the time. It won't be pretty."
There are the top six business principles from Rob Strasser of NIKE, Inc., as described in a Harvard Business Review case study (HBR #9-394-012). How can these principles help groups develop software? Let's review them one at a time.
Our business is change.
Why do we strive to build the perfect system when the business will change,
quickly rendering our "perfect" system obsolete? Given that everything will
change sooner or later, what's the best way to proceed? Clearly we don't
have all the answers, but here are a few suggestions:
First, we believe that you should take the time to build
the best architecture you can with the best database designs. Then build
the system - fast.
Second, concentrate on producing a system that's "good
enough" for the specific task at hand. What constitutes "good enough" will
depend on the system you build. For example, a transaction processing system
must be a higher quality, more robust and precise, than a decision support
Third, build systems in phases. Building in phases
allows you to deliver critical features to the user community sooner and
to change with the business climate.
Fourth, determine how to drop the data into Excel or
into an Access database so that users can write their own reports. If necessary,
provide the users with a junior developer to write their reports for them.
Finally, see our Fall 2000 newsletter, Fast, Cheap and Out of Control?, for more ideas on dealing with rapid change.
Our job isn't done until the job is done.
We have seen far too many development staff members say, "It's not my job."
With everyone running around strictly adhering to their own job description,
sometimes even setting artificial boundaries about where their job ends and
someone else's begins, it's hardly surprising that software gets built
Ensure that everyone understands the big picture, the vision and purpose
of the project and of the organization. Educate staff on the interdependencies
in the process - i.e. how some departments depend on high quality work coming
from other departments. After explaining the vision and purpose, if you still
have hold-outs saying, "It's not my job," show them the door. As a
manager, you need to get rid of people who are narrow-minded. Software development,
like team sports, requires team players who say, "Our job isn't done until
the job is done."
Beware of energy takers versus energy givers.
Every relationship consists of give and take. However, some people habitually
take more than they give. As a manager, you need to minimize the takers and
concentrate on staffing a project with people who give more than they take.
How many systems have gone astray because developers made assumptions about
how the users operated? To clarify assumptions, write mini-specifications
and get the users to sign off on them. Remind the quality assurance (QA)
department that they have to focus on the big picture as well as the details.
See our Summer 1999 newsletter, Dream, Believe, Dare, Do for more tips on resolving assumptions.
We're on offense - All the time.
Too often, software development is re-active. It seems that many Chief Technology Officers (CTOs) spend all their time reacting to the business needs instead of pro
-actively anticipating them. All development managers should say to themselves,
"How can we meet the needs of the business and produce software better, faster
It won't be pretty.
Highly productive software teams are not always fun or comfortable places
to work. Healthy teams have debates and sometimes conflict, usually over
resources or ideas.
We hope that the above pointers will prove useful to you in our software development.
©2001 by Complexity Management
Somerville, Massachusetts, in Metropolitan Boston
Complexity Management Chronicles, a newsletter for software quality
assurance professionals, is published in print form four times a year.
Send your name and snail mail address to the e-mail address below if you
would like to be on the mailing list - at no cost to USA mailing addresses.
Return to Complexity Management Home
Contact Pat Craig at email@example.com .