MEMORANDUM TO: Pat Kareiva FROM: Keith Corbett DATE: June 1, 1987 SUBJ: Planning for Lambda Software Continuation Engineering and Support COPY: Ron Genest This memo is in response to your suggestion that I write up my suggestions regarding software support planning for the future. My proposals, attached, are based on my assumption that we have a significant opportunity to correct the mistakes of the past. This will require implementing radically improved strategies for Lambda software support and continuation engineering. The attached proposals cover the following: 1.0 Re-staff and centralize Lambda software efforts 2.0 Stream-line procedures and communications 3.0 Revamp the price list and maintenance schedule 3.1 Re-structure service offerings 3.2 Raise prices on software maintenance 3.3 Eliminate products / services we cannot support 3.3.1 Obsolete / Hopeless / Ill-conceived LMI products 3.3.2 Troublesome third-party products 4.0 Revamp Education services Attachment KMC [IT:KEITH;SW-PLAN.TEXT] 1.0 Re-staff and centralize Lambda software efforts Many of our problems in the past were caused by differing priorities between Engineering and the rest of the company. We could make major improvements if Lambda software maintenance and Documentation were separated, physically and organizationally, from the R&D efforts in Engineering. Assuming that we need to re-staff the relevant groups (Lambda software development, release control, Documentation, and Support), we should do so in Lowell and thus further centralize Lambda sustaining efforts in engineering, manufacturing, and support. Based on past needs and the current state of the products, we need at least the following staff, as soon as possible, to be ready to respond to a ramped-up sales effort and more active customer base: Support: 3 (additional) - 1 LISP O/S specialist, 1 Unix specialist, 1 communications specialist Release: 2 (assumes Robert Putnam, the only person in this capacity now, will not move from Cambridge) Development: 4-5 (for maintenance alone!) Documentation: 3-5 Documentation is a major sore spot; most documentation needs to be rewritten, and large gaps exist. In the past, customers have identified this as the major failing of our product line; poor documentation increases the support burden by making it very difficult for new users to become productive. 2.0 Stream-line procedures and communications We need more efficient communications between Customer Service and Engineering, including electronic mail between the Cambridge and Lowell Lambda systems. There was a project (partially completed) to centralize bug mail, which we need time and resources to complete. Past efforts to implement the mail link failed because Engineering did not commit to the projects that were attempted. If all Lambda software efforts are centralized, we can use our VAX for in-house mail, but we would still benefit greatly by a link to Cambridge R&D for advance product planning and access to senior engineers. Revamping our Dispatch call handling system is also needed. We would benefit greatly from an on-line system such as ASK/ServiceMan, available for $30,000 as an upgrade to the systems already implemented. Benefits would include: - elimination of PC-based databases and resulting data proliferation problems and in-house support requirement - access to customer histories, field reports, other calls - access to part numbers, sales orders, ECOs - improved statistics and reports for tracking calls, problem escalation, and service planning 3.0 Revamp the price list and maintenance schedule The current price list has several problems. Most software maintenance prices are too low to adequately recoup the cost of sustaining engineering and support. Following are global recommendations and per-product suggestions. 3.1 Re-structure service offerings We should offer software maintenance on most products with a three-tiered schedule. For each product, the following options would be offered (and priced appropriately): FULL: Contracted telephone support, scheduled updates, SIRs (software improvement requests) BASIC: Media and updates, SIRs, 60-day warranty for telephone support of installation only COPY: License to copy software to 2nd system or additional systems Further, the price schedule should reflect charges that increase with the number of LISP processors. The FULL maintenance price would include telephone support for one designated person per processor; additional names could be accomodated for a fee. [This would require beneficial changes to Dispatch call handling procedures; calls would be screened so that only designated callers by customer contract number would be accepted.] FULL and BASIC prices per processor should include extra copies of user documentation to accomodate the extra user implicit per processor. Offering these options requires that we commit to maintaining the current goal on updates (quarterly or semi-annual patch updates depending on the product; annual major version updates). Addiitionally,on-site application development / enhancement and software installation support should be highlighted in the price list. Our "standard rate" is currently $1,000 per day plus travel expenses. 3.2 Raise prices on software maintenance Following is a table showing current prices vs. proposed charges, tiered as above. The proposed charges need to be re-evaluated carefully against actual staffing and resource costs; these are first-guess figures that, I believe, more accurately reflect the hidden costs of support. [Chart on following page.] LMI SOFTWARE MAINTENANCE - PROPOSED PRICES PROPOSED CHARGE (monthly) PRODUCT CURRENT FULL BASIC COPY ------ ------- ----- ----- ---- ZetaLISP $334 - 1st $250 $150 $75 Lambda $167 - 2nd $350 $175 $75 2x2 $450 $200 $75 3x3 $75 add'l user contact System 5 Unix $70 *** $150 $75 $50 L--- -Plus R-Time $62 *** [ ...To be negotiated, ] IKE $62 *** [ if we establish ] Picon free 1st year [ front-line support ] $334 1st copy [ by Customer Service ] $167 2nd+ copy [ ...... ] Vista $70 *** $150 $75 $25 Lambda [+++] $175 $100 $25 2x2 $200 $125 $25 3x3 Iris [bundled $100 $75 $25 Lambda [+++] w/Vista] $150 $100 $25 2x2 $175 $125 $25 3x3 Prolog $62 *** [Drop; see below] TCP/IP $45 [H/W, S/W] $150 $75 $50 Lambda [+++] $200 $100 $50 2x2 [Drop, or fix !!] 3x3 Laser1+ Driver [Not listed] [Should be bundled in with system] Key: [ *** Price per work-station ] [ +++ Continued support should only be offered if enough customers sign up to make them worth our while, since they require extra development / support staffing. ] 3.3 Eliminate products / services we cannot support There are several products we simply cannot continue to support. Of course, we can only support ZetaLISP without major rehiring and development. I am concerned here with products that will never be effectively supportable by LMI. These fall into two categories: a) obsolete or ill-conceived LMI offerings, and b) troublesome third-party products distributed by LMI. The in-house products must be carefully obsoleted or completely revamped; the third-party arrangements should be re-negotiated by Marketing to get us out of the distribution and support loop altogether. 3.3.1 Obsolete / Hopeless / Ill-conceived LMI products a) The MicroCompiler cannot be ported to version 3.0 LISP. I think this one has been effectively "stamped out" by removing it from the price list, but some customers were promised by Sales that it would be ported, eventually. SRL (Wright-Patterson AFB) is still using a broken 3.0 version of this, and our ability to support them is in jeopardy. b) Vista / Iris graphics have always required intensive Engineering support way out of proportion to the customer base. I don't think these are worth continuing, and the support burden is onerous. If we maintain these on the price list, this must be ramped up and re-staffed above the projected requirements I outlined earlier. c) TCP/IP as delivered by LMI has serious short-comings (lack of performance to the standard) and a long list of serious bugs. A major re-write was attempted recently and delivered to MCC over our objections. This is probably a product we cannot afford to drop entirely; it should be re-visited as a new development effort, along with a completely new communications strategy, but this will require a major staffing and funding effort. One of the major problems with TCP/IP bugs has been a lack of access to third-party computers to test the product against; to do TCP right, we need either 1) Arpanet access, or 2) to purchase several other vendor's products, such as Symbolics and Sun. d) The 300-mb removable disk does not work well with a loaded system, and the new SDU software does not work properly with them. This product should either 1) be discontinued / obsoleted, or 2) re-visited in terms of the software support for it, in terms of a) SDU 'load' compatibility and b) acceptable disk layouts / system configurations. 3.3.2 Troublesome third-party products a) Pascal was distributed to about 10 customers through an arrangement with Oregon Software. The vendor won a "hands off" arrangement from LMI whereby we purchase copies and re-distribute them. We are supposed to provide front-line support for the vendor. Although this support arrangement has never been a problem, it could crop up, for example if we ever make major changes to Unix System 5. This arrangement should be re-negotiated, or the product should be dropped altogether. b) LM-Prolog is in a major state of chaos; apparently we owe the vendor, Swedish Institute of Computer Science, over $60K in royalties, so they have not released their 3.0 LISP version to us. I doubt if we ever made that much money from the product; very few customers found it to be useable, and it was a heavy support burden all around. We should abandon LM-Prolog; perhaps LMI (Marketing) could look for a Common-LISP implementation of Prolog that would be industry-standard and more marketable. c) Lambda-E (Explorer with LMI software) was conceived as 1) an easy software port and 2) a lucrative distribution arrangement. Unfortunately, this did not work out as planned. The Lambda-E options should all be dropped from the price list. Alternatively, this needs to be ramped back up, with an additional support person and Engineering resources to complete the port, plus new documentation. 4.0 Revamp Education services Most of our required Education courses -- at least those covering the main-stream product line -- could be delivered by one reasonably proficient person working within a centralized Lambda software organization. This person would have a dual support / training role; this is the best way to recycle expertise and make the most use of a trainer's time. The most important courses have already been developed, but we would need Joe Dreussi's assistance to reconstruct the materials. We need one additional course, to improve customer fluency and lower the support burden, in "Lambda System Management" (including networking).