"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 system.

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 poorly.

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.

Assume nothing.
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 and cheaper?"

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.

***********************************************************************