Mangiaratti On Successful Software Management -- continued In his presentation at a WMSA Workshop on "Successful Software Projects" (Springfield, October 22), the Triad proved to be a useful device in maintaining common focus in a diverse audience. There were twenty five participants representing seventeen software firms, organizational levels from programmer to company president, and two planetary hemispheres. Three visitors from Russia not only broadened the audience profile, but highlighted both the global significance of the subject and the shrinking world caused in part by the very technology of this industry. Conventional wisdom holds that a job completed on time and within budget is successful. Mangiaratti points out that a job completed according to contract specifications on time and within budget may still fail to retain either the customer or the valuable project staff, making it far less than a success for either the software firm or its management. He notes that the word "software" in itself implies that the elements involved in its development are less tangible than hardware or other hard goods produced by the industries in which conventional production management practices evolved Yet, it is clearly a product that is developed to a customer's specifications, rather than a customer service. However, those specifications cannot be reduced to blueprints and bills of materials susceptible to the exact quantifiable measures of in-process material-quality inspection. Specifications may indeed be more than soft, actually fluid, requiring words like "granularity" to capture the nature of component tasks. The good news is that there are words and concepts and tools which can be applied to give ongoing tangibility and process control to the software project manager.

"Granularity" is a good example. Using a graphic, Mangiaratti illustrates the overall software development process flowing from a cloud-like representation of the customer's "requirements" to arrive ultimately at the solid box-like representation of the working "code" that is the final product. The granularity of a cloud -- the size and spacing of its component molecules -- determines it's tangibility in our sight. The granularity of a substance determines how it is contained and handled. As a concept of software development management the molecules of the requirements "cloud" are its component tasks. The size and spacing of tasks (i.e., granularity) is put into a tangible measure -- manhours of work. In practical application, Mangiaratti suggests the ideal granularity in a project schedule fits all tasks within a maximum of 80 man-hours of work. Tasks larger than that should be broken up. Tasks smaller than four hours should be grouped; keeping them as they are on the project manager's schedule is one practical definition of "micro-management". Mangiaratti's approach is neither to pretend tangibility or clarity where it doesn't (yet) exist nor to dismiss the intangible as irrelevant. His approach is to develop practical management tools and processes for containing the real -- though precision-defying -- elements of the real-world environment of software development and application. The key, he says, is neither software nor hardware, but peopleware. Unlike the quality of a manufactured part intended for static fit in a mechanical assembly, software quality is ultimately determined by its fit into the visions, thought processes, predispositions, interests, and even moods of people who are endlessly changing and unavoidably imperfect. This is all on top of the human resource problems inherent in any production process. The manager needed to take all that on is not one who looks for a set of unchanging detailed specifications at the beginning of a project and then sees the job as getting the thing built on time and within budget.

A good manager is one who draws his own direction not from the details of budget or schedule, but from a vision of what the project is all about, derived with the customer at its outset. Appropriate budget and schedules are determined by the vision and subordinate to it; these are tools -- maps --for the manager as he steers along the journey to the vision's destination. It is the manager, and not the schedule, doing the steering, anticipating inevitable changes, continuously taking readings on where the project is, and what lies before it. Always conscious of the Triad, the manager knows he is not alone in the project, that he must keep all three elements (customer, team, and firm management) apprised of where things stand, focused on the vision, adjusting to changes, and united in their expectations. In all this, the manager must constantly be managing "feature creep" (growth in the number of program features, inherent in any software development program) by restricting the growth or adjusting schedule and budget to accommodate it. From the early-on capturing of the vision, through establishing requirements, project life-cycle, schedules, and budgets, Mangiaratti's presentation and 38-page participant handout detailed approaches, techniques, and tools for the Triad-conscious software project manager.

Red Hat's Lisa Sullivan on Linux -- continued Linux accounted for 17.2 percent of all 1998 server operating system shipments -- with Unix at 17.4% and MS Windows NT at 36 percent! That represented 212 percent growth over the year before, making Linux the fastest-growing server environment in 1998. Catching the edge of the Linux wave, Red Hat is widely recognized as the world's leading Linux vendor and now operating with formal alliances with IBM, Compaq, Novell, Oracle, Intel, Netscape, Dell, Computer Associates International, and Hewlett Packard (the first six with equity positions in this privately held corporation). Whether software product specifications originate with customers or with a software firm interpreting customer need, the traditional market model draws a clear line between the roles of provider (software proprietor) and customer (paying consumer). Someone owns the stuff, and others pay to use it. Owners closely guard trade secrets and rigorously enforce their proprietary rights. Purchasers are typically forced to conform their operations and methods within the limits of the commercial software. Sometimes they'll develop their own -- burying the code in their own vaults and, if they market the executable software, it's with the same strings and price tags attached. More often than not, internally developing software to supplement purchased packages is reinventing a wheel already turning within the walls of some other user firm for whom the commercial product fell short. Open source development did not -- as expected -- lead to the balkanization of the Unix market, but in fact movement toward homogeneity. The traditional market assumption was that the few custodians of commercial sector decision-making served as a check against chaos inevitable with free-ranging development in the hands of the consumer mob. As it turned out, too many hands did not spoil the soup after all. In the first place, quantity did not preclude quality as the technologically astute shared ideas and development in unanticipated harmony.

Secondly, where those outside the expert core needed technical assistance to use the non-proprietary code, the assistance itself could be provided commercially. That in turn added a quality filter in the code-distribution process, inserting software quality assurance into a production system where ongoing product is copied rather than built. Quality achieved is quality transmitted. A multinational noncommercial software production system emerged under its own energy, built and shaped not by interpreters of consumer need, but by the consumers themselves. The consumers not only provide the software product specifications or applications design, but the software product itself. The product's function and design are inherently in full conformance with consumer need, the fundamental prerequisite of consumer quality. The development "staff" is enormous, spreading across the consumer population and not limited to a software development firm's payroll capability. It is there simply because the nonproprietary nature of the code allows it to be there -- no restrictions on modification and adaptation. That provides not only an explosion of useful applications but almost as many test sites -- so the quality-checking program begins with the already best-working applications. Red Hat -- or any Linux software firm -- needs heavy budget outlays for neither software development, nor market promotion. The product task is not development, but quality assurance on the flood of developments; and as just noted, even there the consuming population takes on much of the role and expense. The market task is not to promote interest in the software, but to keep up with interest advancing faster in the user population than any company campaign could ever promote. New customers for the Red Hat package may in fact already be users of the nonproprietary code -- not usually the case in the traditional market model. The challenge is not to spread the message of Linux, but to track where the message has already gone and then let people know that Linux is in the Red Hat box.

Of Bots and Brains -- continued critical need that these words first be "key ingredients" in recipes irresistable to the intellectual appetites of site visitors. Even the correct ingredients in wrong amounts and improperly combined will mean a culinary disaster, producing the aforementioned fishing lure that attracts but gets no bites. Visitors do what search engines do not do: they think; they decide whether or not to go on to the next line of the site message, let alone to the point of the ultimately intended action. Ironically, to be a truly effective SEO writer, it is wisest to first design the site and write the text with no consideration whatsoever for search engine optimization. Whatever the sought subject material, searchers and search engines seek real substance, not stuff artificially molded to conform to the search mechanics. The "key words" entered by seekers into search engines are not words they want to encourage websites to use, nor even to find in websites, but rather the words they hope will be clues to the presence of the real substance they want and need. They are the words the seekers guess the websites would naturally use in straightforward presentation of the intended subject matter. A new visitor does not arrive at a website with a keyword check list or score sheet, but rather with a collection of incomplete notions (to be completed by what they seek) which will help them spot clues to information relevant to their specific personal need. Expecting variety, complexity, and junk (non relevant elements), they will be relieved, pleased, and encouraged to be patient in their relevance-seeking by clarity, ease of discovery, and non-distracting creativity. Every newspaper reader and website visitor scans the broad page, homes in on specific areas, and proceeds from one sentence to the next intuitively asking one and only one question: What's in it for me? So, write the site text that way. Welcome the visitor as an individual with a "me" and not an "us" self-conception. The herd approach works for the search engines, but is distracting and even destructive to rapport with consumers addressing personal need. Put yourself in the individual visitor's shoes. Write about

the site's subject matter from the perspective of its substance and its utility for thinking consumers, i.e., how it will answer the "What's in it for me" question, and not as some thread for stringing together the keywords to lure a brainless bot. The herd approach works for a real estate agency's newspaper ads, but the agent who could not distinguish between that and my needs as an individual home seller would never land me as a client. He did not put himself in my shoes. I, on the other hand, as seller, put myself in the shoes of potential buyers. The detailed ad I wrote answered the "What's in it for me" question so fully for the three buyers that they came ready to buy. The successful buyer, who made the first offer, later joked that his advantage over his two competitors was that he apparently was the fastest reader. The businessman, the real estate agent, took the "What's in it for me?" approach for himself, but saw all consumers as a herd following a single mindset, the collective "us." He failed to put himself in the consumers' shoes. Truly putting one's self in a website visitor's shoes makes it unavoidably evident that those shoes are in the website and not anywhere in the search process! They have stepped beyond the search function and past any and all relevance of search engines or any need on the visitor's part for "keywords." Certainly, search engine optimization does have to be ensured, and that will require the presence of the keywords; but SEO and the sacrosanct keywords are still not in any way necessary elements of the strategy to keep the visitor on site and guide him/her to the ultimately desired action. Search engine optimization means providing clues for searchers to find and visit sites most meaningful to their purposes. These clues -- call them keywords -- provide keys to the content of the sites. It logically follows that the keys are derived from the sites which, in turn, have been developed purely to suit the searchers' needs, and not to suit the keys. There is a science to deriving the chronological order from the logical order; but it is not rocket science.