Business Development: Sales By Other Means

"Business Development is the continuation of sales by other means..." --what von Clausewitz might have said had he worked in the software industry

Marketing, Engineering, and Sales define, promote, build, and sell the goods. But what do the "biz dev" guys do?

(This article was originally written in 2002.)

"Business Development" is perhaps the least-understood of the major functions in enterprise software companies. It's defined a million different ways, and consequently ends up in a variety of organizational positions. In some cases it means direct sales, in many cases lead generation, in others M&A, in still others "channel management" (getting others to sell for you), and in a few it's a staff planning job.

Obviously how it's set up reflects the nature of the business, and we'll look at that in detail. But boiled down, "business development" actually develops two things: channels to sell through and products to sell. You're either trying to get others to help you sell, or you're finding others' products (or services) to complement your own. The common denominator is sales. Successful business development drives more revenue at better margins than what a firm could otherwise accomplish going direct, with its own products alone. According to Rob Wright, Associate Editor at VAR Business, 80% of partnerships fail. The leading cause of death is surely that no real business preceded or followed them. (We should all be so lucky to have partnerships that fail because one or both sides get greedy about their shares of a big pie they have created together.) Accordingly my focus here is principally on starting and building them.

Much like sales, successful business development starts with good answers to questions like:

• who would find my products and services useful to providing a more complete solution to their target customers?

• how would our respective pieces fit together? what alternatives do they have?

• how much could it be worth to a prospective partner to work with us?

• how much is a prospective partner worth to me?
  

At a tactical level, building partner ties also closely parallels sales practices:

• find contacts who understand the logic for the partnership, and have reasons to care about it;

• get their attention with something small but meaningful: bring them in on a sales lead you have developed directly -- and don't get too greedy early on!

• if you can close a sale together, you'll have their attention for discussions about how to go to market together more effectively;

• offer to up the ante, but only if your raise is matched by a corresponding commitment from the partner; for example, suggest an investment to better integrate with the partner's product only if they will "market" your combined offering broadly into their sales force, or spend on co-marketing to customers;

• as the volume of business you do together expands, make sure there's clear responsibility and sufficient time within both organizations for managing the relationship, so temporarily mis-alignments between your sales guys and theirs don't compromise a good thing;

• hedge your bet; keep an eye out for encroachments and alternatives -- your partner is doing the same no matter how much business you do together. "Trust, but verify."
  

Naturally, all of this applies equally well in reverse, if you are the "hunted" and not the "hunter". For example, the price of entry for people who want to do business with you should be a fee or a deal. It's really all a question of momentum and market power, of who needs whom more.

Case Study: ArsDigita Corporation

Background

ArsDigita Corporation was an open-source software company. (The company was sold to Red Hat Corporation, another open-source software distributor, in February of 2002.) It focused on "enterprise", as opposed to desktop software, and applications, as opposed to, say, underlying operating systems, databases, and application servers (though as we shall see these lines get gray). More particularly within the enterprise application category, its software is a development framework used to build highly-customized content management and "collaboration" web applications. An example of the former would be WGBH.org, where the ArsDigita Community System (ACS) supports both external users of the site, as well as the authors, editors, and publishers behind it. An example of the latter would be ShareNet, Siemens' global knowledge management application, or Photo.net, one of the web's most popular photography sites.

ArsDigita earned its revenues building and maintaining custom applications using ACS as the starting point. Toward the end of its independent life, the firm was building an application on top of its open-source framework that non-technical end users could use to configure collaboration-focused applications without writing any code. This application would have been offered under more conventional "commercial" or "closed source" licenses, with the hope of supplementing ArsDigita's lower-margin, harder-to-scale services business with higher-margin software revenues.

Although the open-source aspect of the business makes ArsDigita a little unusual, its ultimate intended revenue mix, business model, and partnering strategy would have been no different than, say, a typical ERP vendor's. For example, 57% of Oracle's revenues came from services in 2001.

Target Partners

So whom did it make sense for ArsDigita to partner with? Business development efforts are usefully organized into buckets called "partner programs". Basically a partner program consists of people who have similar reasons for wanting to do business with you, and whom you envision doing business with in roughly similar ways. At ArsDigita, we organized them into:

• strategy and industry consultants
• "digital designers"
• systems integrators
• independent software vendors

Experience

Strategy and Industry Consultants

Strategy and industry consultants include at one end such firms as Bain, McKinsey, and the Boston Consulting Group, and at the other individuals or small partnerships.

The logic for partnering with the large strategy firms was that they would be at the forefront of helping their clients figuring out how to adapt to and include the Web in their businesses. Because packaged software did not always fit their clients' often experimental requirements, our custom application development services -- built on a free and already-proven substrate -- would hold significant appeal. We also did not position ourselves as a one-stop-shop. We had no business consulting staff to compete with theirs. As these firms scrambled to compete with high-flying upstarts like Scient, Viant, and Sapient, we presented ourselves as the ideal complement for fighting back: our elite engineers working with their elite consultants.

This worked out pretty well at first. We had referrals from all three leading international strategy firms. We closed nearly $5 million in business through these relationships, despite our own very low profile in the industry. We were invited to speak at all three firms' global conferences on e-business, giving us exposure through their partner groups to many Global 2000 senior executives. One firm added us to its formal partner program (great PR for us at the time), invested in us, and incubated one of our first European offices. Two of the applications we built in partnership with these firms won industry awards in their respective categories (a third was a finalist).

These relationships were informal and low-profile, driven by relationships developed with individual partners and managers in various offices. They involved no compensation for referrals in either direction, since their objectivity is of paramount importance to them, and they generally get involved ahead of us in the e-business food chain. Our most ambitious "co-marketing" efforts involved our participation, either as featured speakers or as panel members, in seminars hosted by individual offices for their clients and staff.

Later, with the passing of the dot-com phenomenon, large corporations got a lot more conservative with their spending on the Web, both in terms of how much they spent and what they spent on. And instead of hiring the strategy firms to figure things out for them, many brought that capability in-house. The strategy firms' "incubators", supporting both their clients' and their own ventures, ramped down, and with them so did our revenues through this channel. It's pretty clear that our success with this firms in this category, who don't partner very frequently or formally, was driven by unique time and fit. Looking ahead, it would be a stretch to think it could be easily replicated.

We also did pretty well with small but influential and well-connected industry consultants. Again, as a firm earning its living building custom applications, with deep experience solving a particular class of increasingly visible problems (supporting online communities), we represented fresh thinking to complement their deep experience in a particular business. In short, we gave them a good excuse to call their clients for a meeting.

Unlike their large strategy-consulting cousins, compensation was involved in these relationships. In some cases it amounted to no more than paying them for their advice to us in how to approach different industries and functions. If -- and only if -- they liked us, that advice would also be accompanied by referrals and offers of introduction to their clients. More typically though, in addition to paying for their advice up front, if we were mutually excited about each others' capabilities, we would enter into an arrangement under which they would represent us. In exchange for their services, they would earn a monthly retainer, ususally $5,000-10,000 (for about 30-40 hours' work), and they would earn commissions of up to 5% on deals we closed with them. We typically provided for recovery of some or all of retainers paid from the commissions we would otherwise owe. So really they got paid more or less the way a direct sales rep would, only more generously to reflect the fact that they were generating leads for us, and helping us shape our product and marketing strategy for the targeted sectors.

We built, or were building, four such relationships. All generated qualified leads. They also generated crucially valuable input into product development and the focusing of the value story we needed to take to each sector. Doing things over again, I would make relationships like these a higher priority, even to the point of ramping them in advance of ramping a direct sales capability beyond a core of 2-3 very high-quality reps. How to find them? Check out trade journals. These guys are frequently columnists or even editors. Since they're not publishing Time, more often than not they'll get back to you if you write them an even-halfway thoughtful note that relates your firm to something they've recently written -- especially if it's not a bald-faced pitch but relates experience and insight that extends what they've had to say.

"Digital Designers"

"Digital Designers" include large ad agencies with "online" groups, custom application development firms with strong "front-ends" (strategy and design capabilities), and graphic designers. Even though these folks' offerings sometimes overlapped partially with ours (we didn't do design), our logic for these relationships was that they would need a strong, cost-effective substrate for their work along with strong support, ranging from help-desk, training, and software maintenance to architectural and programming assistance on their projects. We needed these relationships because although we were tightly focused on engineering and didn't think we could also be world-class in design, there was always a design component in our work. It really pays to have a good working relationship between designers and engineers, since the output of their work is inextricably linked -- no matter how "cleanly separated" (as marketing types say) the logic and presentation of the application layers are.

We structured these relationships with commissions for mutual referrals, ranging from 5-20%. At the high-end, we expected to give/get lots of sales and project management support to justify the more sizeable slice off the top.

While we did generate some leads and revenue through this channel, it never really took off, for a variety of reasons. Usually firms like these would have CTO's who would see us as a threat to the "line of business" they aspired to build. Also, the choice of technology to build on in many cases had already been made by the their clients' IT groups, and they weren't always their clients' principal advisors on those selections. As end customers' demands shifted from "web sites" to "web applications" and as the technology for web applications evolved rapidly from the toolkits of the early days to frameworks and packages a couple of years later, the volume of business available through this channel shrank. And finally, we had never made it our top priority to proactively develop partners in this category, since given their relatively small size, the bang-for-the-buck invested in each partnership was likely low.

Systems Integrators ("SI's")

This group's roster starts with the Big Five, and extends to "mid-tier" firms with revenues of approximately a few hundred million dollars (Kennedy Information publishes good directories to help create your target lists). Systems integrators, frequently bundling significant strategy, process, and organizational consulting capabilities with their IT services, help their clients pick, implement, and glue together applications and underlying technologies.

Their businesses are based on keeping armies of relatively inexperienced (~0-6 years post-undergraduate) "consultants" on the road and billable to implementation projects. These projects mostly involve configuration of software packages, typically either through graphical or command line interfaces. Staff productivity is the cornerstone of their ability to compete, so they care enormously about ease of use. They tend not to do custom application development, since it's much harder to scale a business based on less-predictable implementations. Whether true partnerships or structured as corporations, they tend to be fairly decentralized. They usually organize themselves into industry- or functionally-oriented practices. If a relationship with a particular vendor becomes sufficiently extensive, they will create a practice explicitly dedicated to implementing the vendor's products. They will even invest -- Accenture bought a big chunk of Siebel once upon a time -- but modestly and infrequently.

They prefer to work with vendors who have already established market momentum, but will work with an earlier-stage, but potentially more advanced ISV if they perceive themselves to be behind their competitors in a category and need a price or capability differentiator. They will also be inclined to talk with you if the leading vendor squeezes them or is inattentive to their needs. They typically organize their partners into three tiers: "Tier I" ISV's generate a lot of revenue ("a lot" means north of $100 million, in some cases) and get dedicated relationship management, technology development, and market planning/investment; "Tier II's" matter to somebody -- maybe an individual practice -- and will get a partial dedication of someone's time, plus maybe a little co-marketing; "Tier III's" may have done a deal with somebody, or may look interesting for some other reason, and therefore go on a "watch list" that raises awareness but doesn't necessarily fire the imagination (that's what the grapevine is for).

As a firm with a development framework for building custom applications, we were not a good fit for SI's but we tilted away at these windmills anyway. We pitched them on support, training, and maintenance for teams and customers using our software. Our logic for thinking this made sense to them was two-fold. First, we saw an entree: within the breasts of some "consultants" beat the hearts, and sometimes the talents of capable software engineers. At the same time, almost every client, and by extension the SI's project leader for that client, is always frustrated at the constraints most software packages impose on customizability. We didn't want to be Vignette or Broadvision or SAP to them, we wanted to be the scratch for the itches those packages created. We got plenty of unsolicited notes from folks in the trenches at these firms saying they had downloaded our code, and that they liked it and wished we would partner with their employers so they could use it. Second, since we didn't have a license fee, we argued we'd be freeing a pot of money which they could split between lower costs to customers and higher margins for themselves as they saw fit.

The logic for us was also powerful. First, if we could do even a couple of projects together successfully, the grapevines in these places are powerful enough to suck you into a lot of deals very quickly and with little additional effort. Even if revenues done together didn't turn out to be huge, there would be significant branding benefit to basking in the glow of their reflected glory. Second, we thought we'd be laying the groundwork for the day when we could go to them with our commercially licensed packages.

There are three ways to get an SI's attention. One virtually always works, one sometimes works, and one is a complete waste of time and money.

• What always works: bring 'em a deal. Every partner at an SI has a sales quota, and so has real reasons to talk with you seriously if you have room in a deal for him or her. If the project works out well, not only will you do more business with this partner, but word will spread. And if the partner has any juice (to which you will have contributed), he'll be able to swing a little co-marketing support (like an invitation to be a panelist at a seminar), as well as accelerated review by the right people in one of the "technology centers" (or other similar-sounding places where candidate technologies get evaluated for formal partnerships).
  For example, we were approached by a regional sales manager (now a good friend) at a mid-tier SI, through one of our sales guys who knew him and suggested he give me a call. We made sense for them as a complement to some of their relationships, since they were smaller -- only a couple hundred million in revenues -- and the big ISV's weren't giving them much love. So we executed an agreement for commissions on mutual referrals which was pretty generous -- 20% of the first six months' revenues per deal -- to help prime the pump in both sides' sales forces. But even so, we were pushing the boulder uphill until we landed a World Bank contract that had a significant SAP integration component (~$800k) that we didn't do and didn't want to. We brought them in on the deal, at attractive rates to them even net of the commission we took.
  Within a couple of weeks we had their CEO and other members of their senior team in our offices for a joint planning session in which we committed (non-exclusively) to drive $10 million in revenue to each other. Word swept through their ranks, and within a couple of months we were doing the "road show" through their sales regions, introducing ourselves and soliciting leads we could pursue together. It didn't take long for us to put fifty introductions and a dozen leads, some pretty well-qualified, into the pipeline. (Timing is everything. Twelve months before we'd have been riding a rocket ship, but this was September of 2000. We didn't hit that target, unfortunately, but even more sadly they had to seriously retrench their own business by the summer of 2001.)

• What sometimes works: lead their thinking. Some big SI's have institutes built around rain-making gurus on various topics; at minimum they have practice heads and since their business is built on advice they have to stay somewhat at the leading edge of their fields. If you are able to present the experience and learning that underly your stuff in a way that is relevant to an SI's practice, you'll sometimes get a meeting.
  
  
  For example, on the basis of our very successful work with Siemens, we had written a whitepaper on what we had learned about deploying knowledge management solutions. We saw one of the Big 5's KM gurus quoted on this application in a Business Week. We wrote him a note, introducing us around "our joint client", and asking for a visit to share what we had learned. Against odds -- they had recently downsized and were certainly not in the mode of broadening their ISV partner set -- he replied, and we had a very productive meeting. He referred us to the head of their KM practice. This person also cautioned us not to get my hopes up, but again on meeting live we had a very positive discussion and he lined up three partners, each with potentially interested clients, for us to speak with. This too went well -- a call scheduled for an hour went twice as long. Next step: introduction to at least one client. (Again, fate cut this thread short, as ArsDigita was sold and I left before we could proceed to the next step.)

• What never works: go through their formal alliance program channels. Because you will be asked if you have done so when you approach one of their partners, you have to go through the motions of applying. But progress will be slow unless you have a champion. Though not as open and bald-faced about it as the big ISV's, SI's -- especially the big ones -- know their time and brand have value, and will occasionally try to charge "evaluation fees" if times are tight. I have at least one senior acquaintance who claims to have personally experienced this at another company, though I have not. Even if you make it all the way through and are accepted into the inner sanctum of approved technologies, people are conservative and will use what they know until somebody shows them they can make money with your stuff.
  

It's the fondest dream of every bus dev guy working at an enterprise software vendor to build a partnership with a Big 5 SI. But the reality is that not every ISV is ready, and you can waste a lot of time trying. We weren't ready. Our technology was in the middle of an important architectural transition to bring it into the mainstream. Our focus on customization and our open-source distribution model made us look like competitors with their core business, no matter how hard we tried to explain why this was not the case. (It turns out some SI's were resellers for major ISV's, earning a nice -- around 30% -- slice of the ISV's license fees in the bargain, which may have skewed their vision somewhat. I had a fellow at one of the three largest SI's in the world patiently explain to me, after listening to my pitch about our open-source model and the value it freed up for them, that we could keep all of the service revenues, but they -- "Cesar, are you sitting down now?" -- would take 60% of our license fees under their normal reseller terms. I jumped on that: 60% of zero sounded pretty affordable to me. I asked him to fax me the papers ASAP. The fax didn't come, but I did get a sheepish call 24 hours later saying that under the circumstances they might need a slice of the service revenues. I pretended to be annoyed for a few seconds, then suggested a deal, but the poor guy lost his job a few days later in a RIF. I should probably have moved on earlier, when he admitted he'd never heard of Linux -- which seems absurd today, but was possible in 1999.)

Having advised that it's smart to take your cuts at a Big 5 only when you're ready, it's also useful to have a constant reconaissance networking effort underway on these folks. You need to understand not just how they're organized and who they're partnered with (which you can get from a web site), but the human realities involved: "So-and-so's not really part of that practice, but he's really the guy to talk to about e-commerce solutions for off-balance-sheet partnerships", or "Yeah, we've done a lot of XYZware2000 implementations, but we're really tired of all of the workarounds required to get it to work." Traction with these guys takes a long time, and it pays to keep the embers of any contacts into them warm.

Independent Software Vendors ("ISV's")

Our efforts in this category were principally focused on vendors of the underlying infrastructure our software ran on, most immediately the application server vendors: BEA, IBM, Oracle, Sun. We figured that since they have huge sales forces and everyone has to come through at least one or more of them for critical pieces of the technology stack for web applications, it would make sense to be one of the things their sales guys carried in their bags.

If this was obvious to us, it was certainly obvious to them. All of these vendors have partner programs for organizations of different sorts. The main difference between them and us was that they have the market power to, as our founder used to put it, "turn you upside down and shake you until the money stops coming out." Not unlike political campaigns, there were different levels you could sign up for, each entitling you to increasingly exalted stature in their partnership pantheon.

For a fee ranging from free to a few thousand dollars, you could become a "developer partner", which would get you listed as such on their web site and get you a few developer licenses to fool around with. This is in most cases an annoying but unavoidable hurdle to clear. Becoming a developer partner also allows you to say you're a partner and use their logos in certain ways. The most common is to splash it up on your web site's partner page to glean some tiny reflected benefit from the association. We passed on doing that, because we just felt it would make us look even more pathetic than we actually were.

A second way to try to "make them your friend" is to sign up for their marketing teams' solicitations to join them in their massive ranches at trade shows. For sums ranging from $7,500 to $20,000, depending on the placement and the show, you can have your own little booth under their big arches or banners or whatever, showing off how your latest stuff runs so smoothly on their technology -- an additional investment they expect you to make, rarely with no direct financial support (though they will make their engineers available to help smooth what their marketing people claim is "seamless").

(When we were young and naive, we once spent $5,000 with a major ISV for a kiosk in their "pavillion" at Oracle Open World. While it generated few leads, it turned out to be worth it because we got lots of our local engineers to "man the booths", which is to say one or two hung around to give demos and collect business cards, while the other 4-5 roamed the halls gathering competitive intelligence. We learned a lot more about a competing vendor chatting for an hour with their sales engineers (without mis-representing ourselves) than thousands more spent on secondary research could have provided.)

A third, even more significant way to get their attention is to buy a "prepaid". Under these agreements you buy, say, ten licenses at discounts of up to 50% off the rack rate for a single license (which no self-respecting customer pays anyway, especially large ones with lots of seats/ CPU's to cover). You do this because if their components are required to run your software, you may sometimes be able to get a markup on licenses you buy through a prepaid when you resell them to your customer, or at least bid more competitively on a "total-cost-of-ownership" basis. But it's a stiff hit to cash flow for the typical venture-backed firm to step up to one of these, with pretty uncertain returns. We passed on these.

Fourth, When a vendor's market position is really strong, like SAP's was a few years ago, it doesn't open up its API's to you unless you're a paying member of its alliance program. This is a calculated bet on the part of the vendor that there isn't much more market share to gain, and that because its product has become a de facto standard, it should "harvest" what profits it can scrounge up anywhere in its ecosystem. One way around this if you are smaller and poorer, as we were, is to partner with an SI that already belongs and has API access and has a reason to figure out integrating your product with theirs. We did this at the World Bank with our SI partner, and we agreed to jointly own those integrations since we had essentially co-funded their development.

"So far, so good", you say, "but when does the money start to flow in the opposite direction?" We got one major ISV's attention because we were doing interesting things in the relatively early days of the web that showed off their capabilities. They even hired us to build a web application using our software. As big as they are, it took twice as long to negotiate the deal and to get paid as it did to deliver the application, but we got a half million in revenue, a very nice case study with a lovely quote from a very senior fellow out of it, and they vouched for us as a reference a number of times afterward.

With this track record, we were able to network into various corners of their sales force, where we'd meet certain gatekeepers (sometimes field marketing types, often marketing-savvy sales engineers) who would explain what we needed to do to get in front of their people at their national conferences and training programs. We would then haggle a bit: "if we can just do the bare minimum, say install on your raw app server, is there a sales guy out there who would be comfortable going out and selling with us just based on that?" And there would be a couple. (Another major ISVonce offered to bring us in on three named leads for just this small effort on our part.) But you only need a couple to justify making additional integration investments that will increase deal flow.

So the point, just as with SI's, is to get to the sales guys. Sales guys will invariably ask their favorite sales engineers to have a look. If you can get this done successfully in their field organization, rather than going through the corporate alliance group mother ship, it will take less time and have a better chance of succeeding. The best way to do this is to make sure your own sales guys know the target ISV partner's sales guys covering the same customer, and to make initial contacts at that level. Here you will find out what minimum investment is absolutely required to get in the door, not what the product marketing people would love to have. Sometimes with smaller ISV partners it's enough to provide "whitepaper" integration, which is an explanation of how the two technologies fit together and what would be involved in making that happen.

Lessons Learned

If business development is sales by other means, then building a business development program and relationships is somewhat like building a direct sales force.

Like sales people, partners must be prepared and supported to sell for you. At ArsDigita, we created a "Partner Selling Kit". The kit, maybe 12 pages long or so, included one-pagers that introduced us to them, explained the logic for the partnership, and presented a few case studies. But most important were three pages: 1) criteria to identify and qualify a lead that would make sense for us together, 2) the "brain stem", plain-English pitch they could use to introduce us to a customer, and 3) a one-page joint brochure summarizing our offerings. Then we got out on the road and did our customer sales pitch and demos for them, followed by sessions in which we would ask them to present two or three of their customers so we could do a 5-10 minute brainstorm on how we could help each of those customers using our products and services. This approach was very well-received.

Because there was a significant customization component to our applications, we invested a lot of time, both in business development and in sales consulting to and brainstorming with our partners understanding their customers' business needs and tailoring our approach and proposals accordingly. If a partner brought in a qualified lead (average deal size for us was between $250,000 and $500,000 for the first few months' work), I made all sorts of time to help him or her close. We saved meetings for gazing at the belly button of the relationship for when we had a data set of joint pursuits sufficiently large to draw meaningful conclusions (~10 at least).

Communicating both news and wins is critical. Life in the field is lonely. Partners can easily forget you. Newsletters are nice, but letters to the partner's sales force, highlighting mutually relevant developments and signed by both firm's CEO's, are better. Conference calls are great, but live joint visits around customer calls are best.

Though the functions are similar, beware. Selling through partners takes longer. You're competing for air time. You have no formal authority over their reps. All carrot and no stick means you need the right personality on point. Push doesn't work. Command-and-control sales managers are not the ideal fit. The best choice is someone the partner's sales guys want to take with them on calls. Their preference is your leverage. Use it, and manage it carefully.

Early on, don't distinguish between direct sales and business development in your own organization. The partnership between sales and business development in particular is crucial to the success of the organization, and should be established as a tight, peer-level relationship. Every deal will likely have business development requirements and opportunities. Both functions should look at every incoming lead generated directly and thinking about how it could be used to advance partner relationships.

Spend less on the "program machinery" of the business development organization, and channel the savings into hiring fewer but better, more tech-savvy, and well-connected business development executives. Winnow prospective partners approaching you with standards, requirements, and policies that will help self-select in only those that make the most sense; don't set the bar too low and then spend lots on people to screen out obvious no-hopers. It just disappoints them and makes enemies. Press releases are like candy, sweet but short-lasting and completely lacking nutrition. Their principal value in my experience is to notify your partner's sales force of your arrangement in advance of any live communication with them.

Make sure you only put the best, and best-trained, players on the field. In my experience, the best business development people blend successful relationship sales experience (including a track record of expanding sales within customers), deal-making facility (being able to assess the logic for a relationship), and a genuine interest in the customer problems the firms solve together (it makes them better innovators at the point of attack). All of these can be readily observed through references and personal interaction.

--------------------------------------------------------------------------------

© 2002 Cesar A. Brea [email protected]

Note: This commentary is the intellectual property of Cesar A. Brea. This file may be downloaded and freely distributed in electronic form only, provided no alterations are made to the original text, including this copyright notice. One print copy may be made for personal use, but further reproduction and distribution of printed copies are prohibited without the written permission of the author.