Conference heron::euro_swas_ai

297.0. "Fwd: David Stone presentation review" by ULYSSE::ROACH (TANSTAAFL !) Mon Mar 25 1991 14:29

 

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     23-Mar-1991 07:16pm CET
                                        From:     BEANE
                                                  BEANE@BIGRED@MRGATE@DPD03@DPD
                                        Dept:      
                                        Tel No:    

TO: See Below

Subject: Fwd: David Stone presentation review

[headers removed]

From:	GAMBLN::CASHMAN  "PDM1-1/M13 ** DTN 291-0280" 	15-MAR-1991 18:03:41.85
To:	@M:BH-GROUP, @M:MKTG, GLENN, MCATEE, PICCOLOMINI, @M:RETAIL, TOMAS 
Subj:	David Stone on running software as a business

People --

	On 3/13 I attended a 90-minute talk by David Stone, VP, The New
Software Group (TNSG -- basically, all of NAS and layered products).  The
audience was about 150 supervisors and managers in TNSG, and his
presentation was based on a recent one he made to the DEC Board of Directors
entitled "Your Role in Making Software a Business."  Here are my notes and
quotes, with some comments at the end.  

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

        I was asked to talk to the Board of Directors about software.  The
DEC Board of Directors doesn't understand software.  They don't understand
hardware, either.  "You want to know the difference between hardware and
software?" I asked them.  "One makes money and the other doesn't." (See
Table 1.)

TABLE 1: Hardware vs. software profit (Stone's slide also had revenue
	 and engineering expense)

		Hardware profit		Software profit
		(% of NOR)		(% of NOR)

	FY86	10.0%			15.8%
	FY90	(1.2%)			21.3%
	CAGR	10.5%			31.7%

	Stone's organization, TNSG, owns NAS -- the services, tools,
workbenches, and APIs.  This is mostly stuff which used to be in the
operating system, but which has been excised, and must be made to operate on
different platforms and heterogeneous networks.

	If you break the software numbers in Table 1 out into base platform
(i.e, VMS and Ultrix operating systems) and layered products and
applications, you get the following (Table 2):

TABLE 2: Base platform profit vs. layered product profit

		Base platform		Layered products & applications
	
	FY86	20.6%			10.9%
	FY90	29.9%			10.6%
	CAGR	36.1%			22.5%    (Did I copy this right?)

	Stone commented that the profits on the base platform software came
from three products -- VMS, Ultrix, and DECnet -- which effectively means
two products, VMS and DECnet, which REALLY means one product -- VMS.  Thus
we're effectively a one-product software company.  What has to happen is
that the layered products must be moved to more platforms, since VMS
represents only 6% of platforms by revenue and nearly 0% by units.

	How does DEC as a software company stack up against real software
companies (Table 3)?

TABLE 3: DEC vs. real software companies (all figures % of NOR)

		DEC(*)	Micro-	Oracle	Comp.	Novell
			soft		Assoc.
Profits 	10.6%	32.7%	19.6%	20.2%	17.1%
Engr expense	30.4%	15.3%	 9.1%	13.2%	10.2%
SG&A		32.7%	30.6%	54.8%	48.4%	37.9%

		(*) Layered products/applications only

        Looking at the components of TNSG on a profit vs.  growth chart, we
have (Table 4):

TABLE 4: TNSG segments

Segment		Profit		Growth

CASE		High		Low
Office		Modest		Low
Database	(Loss)		Low

	Said Stone, "If I were an investor, I wouldn't invest in me."  The
challenge [for Stone to get money] is to make software an attractive
investment, which means either cutting the expense or raising the revenue
(while holding the line on expense).  He indicated some growth targets for
the various segments and new businesses (security, distributed systems, etc.).

        He also mentioned that investors look at two things in a start-up --
what does the market look like (can you make MONEY) and do we trust the
person leading the company (can YOU make money).  One component of the
latter is -- has the person done this before?  With regard to NAS as a
software business, Stone felt that DEC did have some evidence of having done
it before -- namely, that VAX/VMS and DECnet provided NAS-type services,
although on one hw/sw platform.

	According to Stone, software at DEC has historically been done to
support the sale of hardware boxes.  He used transaction processing as an
example: "We did TP because we needed something to run on the VAX 9000.  By
contrast, if we were interested in getting into the TP software business AS
A BUSINESS, we would have put the software on the most prevalent platform in
the universe -- PCs." He also mentioned distributed systems as one of his
new businesses, and noted that we've never considered distributed system
components as something to be managed as a business.  Instead, in line with
the corporate culture, it's been managed as an engineering exercise in
trying to produce neat stuff which must deal with such complexity that only
DEC could be expected to do it.

        Stone mentioned three "change programs" which TNSG is putting in
place (there were eight programs on his slide).

        One is the Software Architecture program, which attempts to define
the entire NAS architecture and all its components and interfaces (currently
a 375-page document).  This intensive effort has been going on for about
eight months.

        A second program is to improve the software development process
(i.e., quicker time to profit).  Stone produced a slide which showed that
our average product's "mean time to profit" is just over four years --
around V3.0, if the product makes it that far.  Why don't we make money at
V1.0?  Three reasons -- the product doesn't work, it has the wrong
functionality, and the sales force and customers aren't ready for it
because they didn't believe it would be delivered on time.  In traditional
product development, including software, the various stages (requirements,
specification, design, implementation, field test, etc.) are strictly
sequential.  In concurrent engineering, they are significantly overlapped.
But how can you field test a "product" which has been incompletely specified
and only partly prototyped?  Stone claimed that field test had two aspects
-- one being "does it work?" and the other being "do people like it?" He
felt that the latter aspect could be tested by a prototype, providing useful
feedback while the development concentrated on the "making it work."  

        He characterized the phase review process as "product prevention,"
and said that all bureaucratic processes are designed so people could say
"no," whereas entrepreneurial processes are designed to get something done
quickly (even at the expense of making mistakes).  For those who would say
that the concurrent engineering process would cause buggy products to be
shipped, he said that unfortunately that's not new at DEC, and besides, that
would be addressed through the third program, Total Quality Management.

	TQM addresses all aspects of product and process design (see Table 5):

TABLE 5: Total Quality Management aspects and processes

			Fitness for:

Standards		Use		Cost/Benefit		Delight

"Conformance"		"Defect		"Benchmarking"		"Innovation"
OSF, X/Open, etc.	 Prevention"	Quality Function
			Six Sigma	  Deployment (QFD)

					"Cycle Time"
					Concurrent Engineering

        In TQM lingo, products can be "fit" at different levels.  Fitness for
standards means that the product meets someone's standard. This is called
conformance, which we meet by participating in and conforming to various
standards.  Fitness for use means that the product is at least usable --
defect prevention is the buzzword, and Six Sigma is the program we use to
meet this fitness criterion.  Fitness for cost/benefit means it meets the
customer's needs, but nothing more.  Techniques such as QFD for analyzing
customer requirements vs. technical trdeoffs, and concurrent engineering,
address this.  The last category of fitness Stone calls delight -- that 
what you've produced is truly an enabling technology, which the users can
use in ways you never imagined.  There is no process in place to insure that
we produce delightful products.  (In response to my question, Stone named
spreadsheets as an an example of a delightful product.  He couldn't think of
another.)

	In passing, Stone emphasized the importance of predictability,
particularly as regards delivering products on time.  To that end, when it
was 5:00, he noted that his talk was through, since he believes in
deelivering on time.  (In truth, he had finished, and had answered many
questions.)

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

	Some personal comments, and comments from my TMEP class:

        I found David Stone to be an inspiring speaker -- clearly a thinker
and visionary, and one who was willing to speak some hard truths about the
company and what had to be done.  (But I admit to being a sucker for that kind
of approach.) When I asked him to name a delightful product, he obviously
took some time to think about it, and didn't mind giving the impression that
he didn't know it all.

	My classmates, all of whom are from TNSG, were somewhat less
enthralled.  They aren't sure whether he'll get cut off at the knees by the
Executive Committee, or whether he'll be sabotaged by middle management
within TNSG, which consists mainly of people who've been around forever and
have no real interest or stake in changing.  This was emphasized by a point
which our class facilitator made, namely, that Stone did not mention the
human or managerial side of managing this enormous change, except to say
directly to the audience, "It's your responsibility to motivate your people,
and to keep yourselves motivated, because the changes will never end."  Our
facilitator felt that Stone was walking away from any responsibility to help
manage the change, or help work people through the transition.

-- Paul

Distribution:

TO:  Pat Roach@VBE
TO:  Susan Sugar@MWO
TO:  Steve Becker@AQO
TO:  Ed Hurry@DVO
TO:  STEVE DONOVAN@DLO
TO:  DENNIS DICKERSON@DLO
TO:  Czarena Siebert@HSO
TO:  Mike Sievers@HSO
TO:  Mike Willis@HSO
TO:  Sherry Williams@HSO
TO:  Dale Stout@HSO
TO:  Tommy Gaut@HSO
TO:  Tom Wilson@HST
TO:  jim rather@HSO