Kathl K.81...LuclndaM .........

Managing Organizational Handoffswith Empowered Teams

High morale, strong teamwork, and proactive thinking (instead ofreactivethinking) areessential catalysts for the development ofproducts thatmeetor exceed customer expectations. Thetraditional organizational structureinto which development work is segmented can either impede or enhancethe ability ofdevelopers toform effective teams. Because oftheir usual hier­archical form and often rigid boundaries, organizational structures can alsoinhibit the development ofa strong sense ofownership, thereby stiflingcreative, proactive problem solving. This paper describes a way toformempowered teams around traditional organizational boundaries, Le., byorganizing the team into a subproject team. Thesubproject concept wasused effectively inthe development ofa hardware, firmware, and operatingsystem platform for a new PBX. We did notcreate theusual artificial deliver­iesbetween hardware and software organizations through contractual obli­gations. Instead, we formed a subproject thatencompassed all the develop­ment work needed toformulate, test, and deploy the new PBX vehicle. Qual­ity metrics data for the subproject showed anincrease incustomer satisfac­tion, high team morale, and a reduction innecessary rework.Introduction

Many development handoffs betweenorganizations are achieved viawritten con­tracts, in which the sending and receivingorganizations specify their delivery expecta­tions. These contracts are appropriate at somehandoff points. However, webelieve that suchcontracts canalso have a downside. Bytheirverynature, contracts are often legalistic, andcancausefinger pointing andaccusationswhena certain clause is not met. This,in tum,can leadto teamwork andownership that areless thanoptimum among developers.

The subproject teamconcept is analternative to rigid, organizational productdevelopment. In this paper, wedescribe thesubproject concept andhowitwasdeployedin the development ofa large, complex PBXforthe AT&T DEFINrrv® CommunicationsSystem product line. Wealso give a briefoverview ofthe subproject methodology andpresentquality metrics from the PBX develop­ment. In addition, weshare somecomments

from developer andcustomer retrospectivesto highlight the keensenseofownership andteamwork within the subproject. (panel!defines acronyms andterms.)

It is important to understand thatmany ofthe subproject methodologies wedescribe are techniques thatgoodteambuild­ers anddevelopers use everywhere inAT&T.Butthe subproject concept goesonestepfur­ther. It allows us, in essence, to form anorga­nization that is basedon the actual work athand, rather than try to fit the work into theexisting organizational structure.

Although thispaperdescribes theuse ofthe subproject concept fordevelopingproducts acrossthe boundary between hard­ware andsoftware organizations, the conceptcanandshould be usedat other traditionalorganizational boundaries as well.

Project BackgroundThroughout this paper, wewill draw

on examples to illustrate the subproject

22 AT&TTECHNICALJOURNAL. MAY/JUNE 1992

concept. Because wetookthese examples from a realPBX product development, wepresentsomebackgroundinformation on the product before describing the subpro­jectorganizational technique.

SCope of the Project. The RIse (reduced instruc­tion set computer) platform1 subproject waschartered inlate1987. Its purpose wasto coordinate the design,development, testing, and delivery ofthe RIse processorcomplex for the Generic 3 Release ofthe DEFINI1Y Com­munications System.

The hardware for the RIse processor complexconsisted ofthe:- Processor board (which is basedon RIse technology).- Memory boards.- Duplication interface board. (This boardprovides the

connection between the two fully redundant processorcomplexes that are used to ensure highly reliableoperation for the DEFINI1Y system.)

- Massstorage boards (i.e., controller, disk, and tape).- Network interface boards.- System maintenance board.Several ofthe boardshad largefirmware packages (i.e.,built-in programming for the processor, network inter­face, system maintenance, and massstorage).

In addition, a real-time operating system wasported to the hardware. (Ported meansexisting softwarewas adapted andtranslated to work on the new proces­sor.) Significant development effort wasneeded on theoperating system (i.e., kernel, drivers, etc.) to accom­modate the newprocessor and peripheral boards. (Thekernel is a set ofprograms forexecuting an operatingsystem's mostprimitive or basic functions. Adriver isthe set ofinstructions a computer uses to transfer datato andfrom a particular peripheral, e.g.,a memorydevice or a printer.)

The operating systemalso wasenhanced witha newdebuggerthat wascompatible with the RIse com­piler's optimization techniques. (A debugger is softwarethat is designed to helpdetecterrors in a computer'sprograms.)

The RIse subproject teamdesigned anddevel­oped all the hardware, firmware, andsoftware (i.e., oper­atingsystem) needed for the new processor complex.

The SubproJect'. Custom..... The RIse subprojectteamhad several internal customers to whom deliveriesweremade (see Figure 1).These internal customerswerefunctionally organized teamswithin ourbusiness

Panel 1. Abbreviations, Acronyms, and lennacustomer-supplier model- a work process that

emphasizes relationships between the customerandsupplier, processinputandoutput, andrequirements andfeedback

KNCSL - thousand noncommentary sourcelinesofC-Ianguage code; doesnot include comment linesin the code

methodology - the processes, metrics, anddocumen-tation developed fora particular taskor technique

MR - modification requestPBX - private branchexchangePQMI - process quality management improvement; a

seven-step methodology forprocessmanagementandcontinuous improvement

RISC (pronounced risk) - reduced instruction setcomputer; an architecture in which the instructionset is reduced to a minimum to increase process­ingspeed. The instructions used mostoften arebuiltin;othersare donebycombining the built-ininstructions.

unit, who added additional development before the finalproduct wasreleased to market.

Ourlargestcustomer wasthe application­software development community forthe DEFINI1Y sys­tem, which consisted ofabout 115 developers. Thiscus­tomerrequired that the subproject software, firmware,andhardware deliveries be stable, so that developmentofthe extensive application software could proceed onschedule.

Another major customer wasthe PBX testingorganization. Its rolewasto certify the quality oftheentirePBX product before the product wasshipped toexternal customer sites.

Finally, weviewed the AT&T Denver Worksin Colorado as an important customer. Thiscustomer(which wereferto as the factory) expected our designsto fit smoothly into itsjust-in-time manufacturing pro­cesses." andto be easyto build and maintain.

The RIIC SUbproject Team. Overthe life ofthe pro­ject,the subproject teamconsisted of40to 60peoplewho came from about 15 supervisory groups. We (theauthorsofthis paper) werethe co-supervisors fortheentiresubproject, andinterfaced with allthe developers

AT&TTECHNICALJOURNAL.MAY/JUNE1992 23

Systemtest

Subprojectcustomers

Subprojectrelease

--- Deliveries

---- Feedback

Denver Worksfactory tools ,

II

Software -Idevelopment

III~

I IL ..J

Operatlnc system software

•••

Hardware and flnnwarecroaa-functlonal

eubproJect teams

• Suppliers to RiSe subproject

[:=J Rise subproject customers

r,II~III~

I IL .J

Figure 1. The sub­project functionalstructure shows thedeliveries to the sub­project team fromthe various cross­functional teams andfrom the operatlng­system softwaredevelopers. Thesedellverables areIntegrated togetherand then tested as aunit before beingreleased to the sub­project customers.

andmanagers involved in the development.The RIse platform and the DEFINIlY systemsoft­

ware weredeveloped in parallel, and the software wasportedto the newhardware reasonably latein the devel­opment program. Hence, the software development com­munity used interim hardware to develop the software ona parallel development track, while the subproject teamdeveloped the RIse platform. The parallel effort wasdesigned to reducethe overall project-development inter­val, yet have state-of-the-art hardware incorporated intimeforthe product releasedate.

What •• a Subproject?Now that wehaveprovided background on the

DEFINIlY systemproject, weare readyto discussthemorestructural and managerial aspectsofsubprojects.Hereand in the sections that follow, wepresentthe gen­ericconcept ofa subproject and illustrate it with exam­plesfrom the RIse subproject.

Asubproject is nothing morethan a teamthatis managed by a small numberofsupervisors and isresponsible fora broad, easily separable, functional partofa product. Hence, a largeproduct-development effortcanhave multiple subprojects that operatewithin theproduct boundaries.

In a subproject, organizational boundaries aremeant to be ignored, andteam members frequently

comefrom many different organizations. The subprojectteammembers own the development andare empoweredto solve issues. Unfettered by rigid organizational bound­aries, this sense ofownership leadsto creative problemsolving, highexpectations, and improved employee satis­faction and morale.

In our casewith the RIse processor complex,everyteammember's jobwasto identify and resolve anyissue that wasrelated to introducing the new processorcomplex boardsinto the DEFINIlY system product. (Theissuescould be maintenance codeandalgorithms, dupli­cation, factory tools, application interfaces, etc.) Ourpri­mary mission wasto makesure that allissuesabout theprocessorcomplex wereresolved, and that our subpro­ject teammadehigh-quality deliveries on time.

Subproject Prlnclp••• and Technlqu••It is important to acknowledge that just forming

a teamandcalling the teama subproject is notenough.Just as important is to have teamnorms andvalues.Whensubprojects are started, suchguiding principlesshould be statedexplicitly bythe subproject manage­ment. These principles tend to be reiterated many timesbyteammembersand, thus, become the main themesofthe subproject.

Asan example, these weresomeofthe guidingprinciples for the RIse subproject:

24 AT&TTECHNICALJOURNAL. MAY/JUNE 1992

- There will be no "throwing thingsoverthe wall" toanotherorganization. Wewant to minimize the myopictendencies oftraditional handoffs between hardwareand software, andwewant to maximize accountabilityand ownership of issues. (Throwing things over thewall refers to the practice ofcreatingandhanding offa product or processwhose design does notconsiderthe needsor limitations ofthe other design, develop­ment, or manufacturing organizations and processes.)

- Because teamwork is ofthe essence,supervisors mustact as the rolemodels. Minimal escalation ofproblemsbeyond the supervisory level is a keyingredient toteamwork.

- Technical decisions mustbe madeat the developerlevel, with consensusand buy-in. Empowered teamsown their work!

- Wewill makeuse ofsubject-matter expertsto improvequality and shorten intervals. Asan example, while thedeveloper is designing the circuit, independent peoplecanbe enteringthe circuit schematic intothe com­puter, simulating circuit operation, and designing theboardlayout. Likewise, allmodels (including the firsthardware prototypes) canbe orderedand assembledbyfactory personnel.

- Wewill strive forperfection in allwedo,providingexcellent response-timely, knowledgeable,professional-to issuesand questions that our cus­tomersraise. There is no substitute fora competentteam-people makethe difference!

Along with the guiding principles, subprojectsmustuse specific organizational techniques to structuretheirwork. The specific subproject structureis not asimportant as the agreed-on organizational techniquesthat have beenwell communicated andhavethe team'scommitment.

The Rise subproject used the following organiza­tional techniques:- Ourwork will be viewed as a combined delivery to our

customers and consistsofhardware, firmware, operat­ingsystem, and software tools. The subproject deliver­ies will have been completely tested as a unitby inde­pendenttesters, according to extensive test plans.

- To promote furthercooperation among subprojectteammembers, wewill form cross-functional teamswithin the subproject. Eachsuch teamwill have mile­stonesand demonstrations forwhich allmembers ofthe teamare responsible.

For example, weformed a cross-functional teamforeachboardofthe Rise processor complex. The appropriatehardware, firmware, and software developers were mem­bers ofeach such team. For the mass storage team, forexample, a keyfunction to be demonstrated was: savingPBX translation information to disk. Even though, at thehighest level, this was a software function, the hardwareand firmware members ofthe teamwere just as respon­sible as the software memberforachieving the milestone.

These demonstrations wereimportant focalpoints forteammembers, andallowed themto broadentheir scope beyond their traditional developmentresponsibilities.

Figure 1 shows the functional organization forthe Rise subproject. This structurefollowed thecustomer-supplier model,3 whereeach member ofthesubproject teamwasa supplier and the subproject servedas the single point ofcontact forthe customers (i.e., theDenver factory, the software development organization,and the test organization).

Notice howthe structurein Figure 1 minimizedorganizational interfaces andproduced a package ratherthan pieces. This package wasthen delivered as a plat­form to our customers in software development, testing,and the factory. Early in the development cycle, boththecustomers and the suppliers agreedto the quality leveland delivery dateforplatform releases.

Subproject Planning, Tracking, and MethodologyIn addition to guiding principles anda team

organizational structure, subprojects-like mostAT&Tprojects-need rigorin their planning and tracking. Thissection describes someofthe planning andtracking poli­ciesused by the Rise subproject.

While the ideasthatwepresentin this sectionare considered a BestCurrentPractice in many AT&Tdevelopment organizations, sometimes these ideasareshoved aside or overlooked. Hence, reiteration is appro­priate. (InAT&T, a Best Current Practice is a practicethat covers one part ofthe total development process,has substantial favorable experience associated with it,andis considered competitive bymostpractitioners.AT&T Bell Laboratories has a quality initiative thatidentifies, documents, and deploys these practices.)

Oneofthe first thingsthat the subprojectsupervisors should do is use processquality manage­ment improvement (PQMI) 4 to chart the subproject's

AT&TTECHNICALJOURNAL.MAY/JUNE1992 25

Reiddocuments

Hardware andsoftware release

to factory

Factorytests(diagnostic,

x-ray)

Product-designdocuments

FllAi.............U.C.,...

deYeIopment

Allocateheadcount

Set productschedules

Budget

Technicalprospectus

Existingfirmware anddevelopment--------..........,environment

Market needs

Figure 2. The Rise subproject PQMI diagram shows organiza­tional handoffs for the Rise subproject development. Exten­sive cooperation between organizations was needed during

design and development. Application softwareand the plat­form were developed In parallel, so a subproject test wasneeded before the platform was released to the application.

26 AT&TTECHNICALJOURNAL. MAY/JUNE 1992

organizational handoffs. Such diagrams helpmanagersbroaden their thinking, leading to betterplanning andorganization.

Asan example, Figure 2 contains a high-levelPQMI diagram that wascreatedby the RIse subprojectsupervisors.

First, notice the extensive cooperation neededbetween organizations (i.e., forhardware, firmware, andoperating system) duringthe design anddevelopmentphases. Bylooking at the numberofnecessary interac­tions, werealized that the concept ofnot throwing thingsoverthe wall and the concept ofa subproject forthehardware, firmware, andoperating system effort couldgreatly improve the quality ofour design andthe initialdevelopment.

Second, werealized that,because the applicationsoftware wasbeingdeveloped in parallel on this project,weneeded a form ofsubproject test before wereleasedthe platform to the application customers.

Finally, as a resultofdrawing this diagram, weextended our concept ofcustomers, broadening it tocover systemtest and the factory.

Besides having an understanding ofthesubproject's organizational boundaries, eachsubprojectshould also have a basicsubproject development plan.This plan describes such thingsas deliverables, respon­sibilities ofeachsubproject teammember, andexternaldependencies on people outside the subproject. The planshould also document the subproject's demonstrationsofkeyfunctions (e.g.,jirst phone call on RIse hardware)andwhentheyshould occur. Subproject integrationschedules, which showkeysynchronization points forthe subproject, should also be included. In addition,methodology should be briefly described in this plan.

Werecommend that the subproject supervisorswrite this plan and that supervisors in the subproject'scustomer organizations review it.However, webelieveit is critical that the members ofthe subproject teamsetthe datescontained in the plan.

Another important area forsubprojects is theexchange ofdesign andimplementation ideasamongteammembers. Much ofthe team'ssense ofownershipstemmed from the weekly, self-managed, design teammeetings. In this forum ofpeers,teammembers dis­cussedarchitectural issues, tracked action items, andrefined the methodology. The designers followed the

BestCurrentPractice development methodology (i.e.,requirements, architecture, design documents, inspec­tions, etc.) andwereheavily involved in peer-levelreviews at every step.

Finally, subproject teamsmusttakethe initiativeinhelping to headoffcustomer issuesbefore theyhap­pen. Therefore, it is imperative that the subproject super­visors be intimately involved with the various subprojectcustomers. For the RIse subproject, forexample, wehelped write the overall PBX project plans, attended allproject meetings, andtracked milestones in the projecttracking database.

Qu.11Iy Metrics from • R••I SubprojectBynow, readersshould have some understand­

ingofthe organizational andplanning aspects ofa sub­project. Therefore, wecantakea quantitative look at thequality improvements that come from suchanempow­ered subproject team.

This section provides a rangeofmetrics fromour RISC subproject. When selecting the quality metricsandresultsto be presented here,wedecided to show avariety ofmetrics thatwefelt reflected overall quality.Forexample, wepresenttraditional fault ratesandcustomer-filed modification requests (MRS) that docu­menttroubles or problems found byproduct users. (Wereferto these as nonenhancement MRS. An MR may alsobe filed to requestan enhancement.) Butwealso believethat the high-quality design work wedid upfront wasreflected in our ability to demonstrate keyfunctionsaheadofschedule. Hence, wepresentsome scheduledataas well.

PartAofPanel 2 illustrates the size (i.e., thecomplexity) ofthe RIse platform. This information isneeded to understand fully the scope ofthe developmenteffort and the significance ofthe quality metric results.

PartBofPanel 2 contains the subproject's MRdata. It representsallnonenhancement MRs thatwerefiled bycustomers afterthe firstsubproject delivery onFebruary 1,1990. (MRS filed to requesta productenhancement are not included in the data.)

In PartC ofPanel 2,weshow cumulative soft­ware fault rates (since February 1,1990) forthe RIseplatform firmware, operating system, anddebugger.These ratesare aboutten timesless than the typicalsoftware fault rateoftwo to three faults per thousand

AT&TTECHNICALJOURNAL. MAY/JUNE 1992 27

B. Cumulative MRDataSince February 1,1990 (i.e., sincethe first

subproject delivery), customers have filed the follow­ingMRs forchangesother than enhancements:

Package MRcount

Hardware 0Firmware 16Operating system 38Debugger 7

Toad 61

Panel 2. RISCSubproject Quality MetricsHere,wepresentquality metries for the RISC

processor development effort to illustrate the benefitsofthe subproject concept.

A. Project ComplexityThis tableillustrates the sizeor complexity of

the RISC platform. KNCSL standsfor thousand noncom­mentary source lines ofCcode.

D. RISC Platform DemonstrationsThe subproject approach has enabled the

developers ofthe RISC processor complex to meetorbeatschedule dates:

Fault rate

0.12/KNCSLO.34/KNCSL0.18/KNCSL

Unit

FirmwareOperating systemDebugger

Original ActuaIMilestone date date

Operating systemboot 5/6/89 5/2/89Operating systemoperational 5/15/89 5/2/89Bootfrom disk 6/15/89 5/22/89Bootfrom tape 7/1/89 5/22/89Start application port 8/15/89 8/14/89Primary portnetwork phone call 9/15/89 8/17/89Extended portnetwork phonecall 11/1/89 8/24/89Start application development 1/1/90 11/1/89

C. RISC Subproject Fault RatesSince February 1,1990, the cumulative software

fault ratesfor the RISC platform firmware, operating sys­tem,anddebuggerhave beenaboutten timesless thanthe typical software fault rate forsimilar software:

Size

18boardcodes131.5 KNCSL

110.17 KNCSL38.14 KNCSL

Area

HardwareFirmwareOperating systemDebugger

noncommentary sourcelines (KNCSL) ofC code.Another important metric centersaround the

models conversion program wherethe newRISC hard­ware replaced the interim hardware that the softwaredevelopment community had been using. The hardwareconversion wentflawlessly. About 15 systems wereinvolved; andeachwasconverted successfully, withonly about 2 hours ofdowntime needed to replace aprocessor complex. Since then, the models have beenup and running 100 percentofthe time. This representsa vastimprovement overprevious development effortsthat required substantial rework duringthe prototypeprogram, resulting in longspansofinstability and modeldowntime.

Afinal metric shows the subproject team'sabilityto meet (orbeat) expected schedules. PartD ofPanel 2contains our startupview ofthe important subprojectmilestone dates. Notice that it tookonly three days (i.e.,

August 14 to 17) to bringup an entirePBXapplication,instead ofthe projected one month (i.e., August 15 toSeptember 15). Also notice that the subproject customers(i.e., the application software developers) wereabletostart work two months soonerthanexpected.

Retrospective. on Subproject.Wehave discussed subproject concepts and

philosophies andlooked at somesubproject quality met­rics. Now, it is timeto share somecustomer and devel­opercomments about working with andona subprojectteam. These remarks point outthe customer focus thatsubprojects canhave andthe sense ofempowermentteammembers canfeel.

The DEFINITY system's project manager providedthe following piece ofcustomer feedback, which is repre­sentative ofwhatour othercustomers have told us:The quality ofthe delivery was outstanding. Historically,

28 AT&T TECHNICALJOURNAL • MAY/JUNE 1992

the creation ofa newplatform of thiscomplexity is apro­jectmanager's nightmare because it requires close inte­gration ofhardware. firmware. andsoftware. The tradi­tional approach ofeach organization doing its partandhanding it off to the nextgenerally leads tomanyunpleasant surprises. As project manager, I was neveraware ofanyproblems ordisconnects within the RIsesubproject or between the subproject andthe main pro­ject. When the RIse productwas finally delivered, it metorexceededallourgoals andexpectations forqualityandperformance. Interfacing with the subproject was apleasure. The teamhadapersonalgoalof striving forexcellence in everything it did-not onlytechnically, butorganizationallyas well.

After wehad completed our first phaseofdevel­opment (i.e., aroundApril 1990), weconducted a devel­operretrospective, or survey, to obtain feedback aboutthe subproject. These remarksweredrawn from that ret­rospective, and from a later survey:- While this successful development usedseveral

tried-and-true qualitypractices, the overriding commit­ment andambition to drive fora qualityproduct wasachieved through genuinecaring andteamworkamongpeers.

- I enjoyed beinginvolved with thisproject. Therewas seemingly lowoverhead andindependence of sub­groups. I liked the fact thatwedecided the milestonedates and were leftresponsible formanaging the timein between. I also liked working in small, containablegroups.

- The team became essentially self-motivating and. toagreatextent. self-governing.

- We started asaratherunorganizedgroup, tryingtofigure out what to doandhow toproceed. Perhaps.in a way. lettingthe teamstruggle through thisinitialperiod of uncertainty onits own was itselfa team­building exercise. Later, writing documents thatrequired alotofinteraction between people from dif­ferent departments anddisciplines generated a strongsenseof teamparticipation.

- Organizing the project by functional subprojects,ratherthan along departmental lines, fostered team­workby encouragingpeople from different areas toworktogetheratanearlier stage in the project.

- It may soundsilly, butanalmostfamily-like feelinghas developed amongthe teammembers.

ConclusionThere are many ways to manage a team. This

paperdescribed the benefits oforganizing around a sub­project whereorganizational boundaries are minimizedand the customer becomes the major focus. By usingthis approach, the DEFINIlY system's RISC processorteamachieved excellent resultsin terms ofquality deliv­eries,customer satisfaction, and improved moraleamong teammembers.

Otherswho are interested in usingthe sub­project approach can do so by scrutinizing their productdevelopment and identifying large, easily separablepiecesofdevelopment work that spanorganizationalboundaries. These work areascan then be organizedinto subprojects.

AcknowledgmentsWedidnot invent the subproject concept. The

technique has been usedsuccessfully at AT&T on otherPBX development projects, perhapson a smaller scale. Itis alsojust a good, common-sense technique thatgoodteambuilders intuitively understand anddeploy. Weacknowledge previous uses ofwhatweare calling asubproject.

Wewould also liketo thankTonia Wright,Ken Roberge, andTomFisherfor their keen manage­ment insights; and the members ofthe RISC processorsubproject for their sense ofownership, energy, andhard work. TomFisherdeserves special thanksformanaging our subproject testingefforts.

References1. I. R. Mashey, "RISC, MIPS and the Motion ofComplexity," Proceed­

ings ofthe UniForum Conference, February 4-7,1986, Anaheim, Cal­ifornia, USR Group, SantaClara, California, 1986, pp. 115-124.

2. ]. D.Carboy, G.Foo, L. P.Jones, L. E. Kinney, and D.C. Krupka,"Striving forManufacturing Excellence at the Denver Works: ASummary," AT&TTechnical Journal, Vol. 69,No.4,July/August1990, pp.5-18.

3. R. B.Ackerman, R.]. Coleman, E. Leger, and]. C.MacDonnan,Process Quality Management andImprovement Guidelines: Issue 1,SelectCode500-028, AT&T Customer Information Center, Indi­anapolis, Indiana, 1987.

4. AT&T, PQMI: Tips, Experiences, andLessons Learned, Select Code500-446, AT&T Customer Information Center,Indianapolis, Indi­ana, 1986.

(Manuscript received October 23, 1991)

AT&TTECHNICALJOURNAL.MAY/JUNE1992 29

Kathleen K. Glass is a supervisor in the Integrated SystemsDevelopment Department with AT&T Bell Laboratories inDenver, Colorado. She is responsible for the development ofhigh-performance processor subsystems for AT&T's line ofDERNITYCommunications Systems. Ms. Glass joined the com­pany in 1979. She has a B.S.E.E. from Virginia PolytechnicInstitute and State University (Blacksburg, Virginia) and anM.S.E.E. from the University of Colorado (Boulder, Colorado).Lucinda M. Sanders is a supervisor in the Advanced SystemsDepartment with AT&T Bell Laboratories in Denver, Colorado.Her group develops software for the Generic 3 Release of theRISC platform. Ms. Sanders joined the company in 1977. Shehas a B.S. in computer science from Louisiana State Univer­sity (Baton Rouge, Louisiana) and an M.S. in computer sci­ence from the University of Colorado (Boulder. Colorado).

30 AT&TTECHNICALJOURNAL.MAY/JUNE 1992