Conference 7.286::digital

    A couple of thoughts...  (my opinions, of course :-)
    
    EIS is here to stay.  As hardware becomes more of a commodity, to
    survive, Digital must continue to show added value with things like
    Systems Integration business.  We have already invested in good people,
    trained them, and now must go off and sell them (either directly, as
    PSS residents, or indirectly, delivering projects, managing programs,
    etc.)
    
    First hand observations lead me to believe that it's getting easier for
    customers to justify $100-150/hr for EIS services from Digital (as
    opposed to $40-50/hr from independents), mainly because they see the
    added value Digital brings to the table.  If done right, EIS projects
    can contribute big margins to Digital (and are, in many places.)  Add
    to this things like Assets packages (which cost Digital next-to-nothing
    to develop/se) and we're positioning ourselves  well for the days ahead
    when commodity hardware and open systems make hardware/software vendors
    a dime a dozen.
    
    Was it a must to reorganize ?  Yes.  Was it a political game ?  Isn't
    everything ?  Will EIS stay ?  If it doesn't, then (I believe) we're in
    serious trouble - we can't compete on hardware and packaged software
    alone.  Is EIS contributing ?  Most definately - both directly (sheer 
    dollars) and indirectly, by positioning Digital as a vendor that sells
    more than a fast box running an open operating system.

re: 1318.0                       What is EIS?                        No replies
>
>
>
>EIS has been implemented for a while in the company. In this part of the 
>world, I heard a lot of comments, rumours and compliments. I wonder how's 
>the response in U.S. and Europe Area.  Is it a must for the company to do 
>this re-organization or it is a politic games for the senior management? 
>Will EIS stay or it will gone after 2-3 years?  Is EIS contributing or 
>hurting the company? 
>

My opinion (.. drumm rolllllllllllllll) ...


A few years ago there was a computer company that sold piece parts to
customers, and finally assemebled these parts in a minic-computer.
This same company then sold hardware, cables, and software to
customers. A very tiny group mad "Custom" intefaces in very smal
quantities to customers needing to connect the minicomputer pieces to
other vendors hardware pieces, and sometimes wanted an entire
"solution" (hardware, software, special pieces) and have it all
working from the dau it was installed. 

This small group was call Computer Special Services (CSS), and
quicklu earned itself a bad name within the company. 

Since 1985 (when i started with the group) it skyrocketed and
spearheaded a thing called "profits", and used innocative methods to
contain costs, and increase RETURN. 

Today, the world is looking for "solutions". We are doing quality
circles to lead the company into improvded "everything". Learning to
work a differet way to increase Customer Satisfaction, Profits, and
Employee morale. 

CSS and SWS merged to become EIS, and has portions of CSSE has also
merged with EIS. 

EIS is leading the company into the 21st century, by providing- 
- Faster Develoment cycles 
- Improved morale 
- Higher profits 
- Improved customer satisfaction 
- Turnkey solutions to business 

to name but a few. 

EIS isn't just a group. 

It is a new way of doing business and managing risk. 

-BobE 

    To correct the previous note, EIS (Enterprise Integration Services) 
    was formed from THREE groups -- Professional Software Services (PSS), 
    Computer Special Services (CSS) and Customer Training (CT).
    
    PSS was the part of Software Services that developed custom software
    for customers, integrated off-the-shelf software, modified
    off-the-shelf software, converted software to run on the VAX/VMS
    platform, provided general consulting and managed customer projects and
    programs.
    
    Bob Early has described CSS in the previous note.
    
    Customer Training was part of Educational Services, and provided
    off-the-shelf and custom training for customers.
    
    About a year ago, these 3 groups were merged into EIS and chartered to 
    lead the systems integration business.  Additionally, EIS formed another 
    group, called DCCs, (Digital Customer Center) to further support the 
    SI business.  The DCCs now appear to be in a dual-reporting role to EIS 
    and the ABUs.
    
    EIS is here to stay in some form or another.  The recent merger of 
    EIS and Customer Services (formerly field service) at the corporate 
    level suggests the ultimate move to a single services organization.  
    I expect that this would be a political/management change only, would 
    reduce redundancy of certain efforts, and maximize use of resources.  
    The services that we provide are here to stay and are expected to become 
    a major (50% by '95 is the # I seem to remember) portion of Digital's 
    business.  

Re: .2

You've got to be kidding.  Are you referring to the same EIS organization that 
I am forced to try to work with?  Over the past year, I have tried to sell EIS 
business to Digital customers who really need it.  I have found that our local 
EIS organization consistently overbids (too many hours) every potential project 
that we propose.  These padded bids are made more difficult to sell because 
the large majority of hours are at $140/hour.  First, let me make clear there 
are some very competent specialists in our EIS group and they are not the 
source of the difficulties in winning EIS business.  

One example: 

We recently were bidding on a *very simple* system for a trailer leasing 
company (less than 10 screens, less than 5 reports).  Having lived a former 
life designing and implementing systems for Andersen Consulting, I decided to 
try to get more accurate estimates by developing a system design that we could 
use to understand what needed to be done. After several meetings with the 
customer, I developed  a system design, database design and module designs for 
each program that needed to be developed.  We worked with EIS to estimate the 
project on a program by program basis as well as project task basis (including 
project management time, training, user manuals, system test, etc).  We came up 
with detailed estimates that worked out to approximately $200K.  After meeting 
with the EIS manager and incorporating risk, the price increased to $290K.  
However, with a 20% discount that EIS obtained the cost was $225K.

At this point, all that was needed was for EIS to prepare a business package 
and obtain final approval from the EIS manager.  At 2:30 pm on the day the bid 
was due, we were informed that the District EIS manager had re-estimated the 
project and after the 20% discount, the price was $389K - almost double.  In 
the end, we were never told (even though we asked) where the additional hours 
came from.  We didn't just lose the project, we also lost $1.2M in hardware and 
software - and a month of very hard work.  

This is just the most recent example.  I could describe two other similar 
failures within the past year.  It seems to me that there is little interest 
within EIS for providing accurate estimates and trying to win business.  Anyone 
can develop ridiculously high estimates for projects and feel confident that 
they can be met.  

What I would like to know is this:

1) Does EIS have goals specifically directed at selling EIS software business?  

2) Are there other (contradicting) goals that are more important such as 
   profitability, etc. that are reinforcing bloated estimates?  

3) How can Sales be expected to sell EIS business if estimates are outrageously 
   high?  

4) Should Sales ignore the EIS organization and team up with third-party 
   software consulting companies? 

5) Is this just a local problem or one that others run into? 

This really concerns me because I agree with .1 that it is very important that 
Digital provide more software and integration services in order to be 
profitable in the coming years as hardware becomes a commodity.  It also is a 
big competitive advantage for Digital to provide total solutions to customers.  
Many other computer vendors can't match our potential to do this.

- Steve

    Not knowing your situation it is impossible to respond to your belief
    that you were given "outrageous" and "bloated" estimates.  I have often
    seen the case that estimates did not match what was desired by sales or
    the customer.  In this case the options are to sell it as is, reduce 
    function, walk away from the business or loose money.
    
    EIS is not measured on 'selling' its services (sales is) but on
    delivering services (revenue).  EIS is also measured on profitability
    (as will the sales force soon).
    
    Sales, EIS and Customer Services are supposed to function as a team
    with each group trusted to 'do the right' thing for the customer and
    for Digital in preparing solutions.  The right thing for the customer
    is usually the delivery of a valued and quality solution.  The right
    thing for Digital is to do it profitably while leaving a happy customer.
    
    Teaming with and subcontracting to third parties (while insuring
    profits to Digital) is part of the EIS business model and I've seen
    this done a number of times (even done it myself).
    
    Peter Dillard
    Former EIS now Sales Support Unit Manager
                                                                          
    

>Re: .2
>
>You've got to be kidding.  Are you referring to the same EIS organization that 
>I am forced to try to work with?  Over the past year, I have tried to sell EIS 
>business to Digital customers who really need it.  I have found that our local 
>EIS organization consistently overbids (too many hours) every potential project 

>- Steve

My comments are based on my viewpoint, that of providing hardware customer
support to th Call Support Centers and to Customers (all of them).

When I began with CSS (modems), it was a fragmented, low customer opinion
business. As part of the modem team, we grew from a fragmentized coalition
of diverse groups to a unitized focused business, and made a model for
the rest of the business to follow. The "Business Management Team",
which is held responsible from phase 0 to 5 for the products.

The team was a huge success, and support calls grew from a few
discontented to many queries, adn as the suport databases grew
fat with helpful information, CLDs and Prisms shrunk to a negligible
zero.

As the rest of the business matures, and alliances are made, and 
business focus gets put into place, the existing problems (as described),
hopefully, will become less common.

A new notesfile has been started, adn I would invite all members of EIS
to read the opening comments in 1.0.

EIS/E Organizational Excellence / TQM
Created: 10-DEC-1990 13:56          5 topics          Updated: 17-DEC-1990 12:54
File:        CSS::SYS$SYSDEVICE:[NOTES$LIBRARY]EIS_E_TQM.NOTE;1

Excellence comes by doing.

-BobE

re: .4

To start off, the perception "our local EIS organization consistently overbids"
is not unique, although it's off the subject, since people have complained the 
same complaint when the organization was known as SWS. I don't think it's "the 
rule", but yes, I agree it needs to be addressed if it is in fact true..

However, my main reaction to your base note is this except:

  <<	After several meetings with the customer, I developed  a system design,
  <<	database design and module designs for each program that needed to be 
  <<	developed.

System design is a valuable service which EIS performs for pay. If you gave a
conscious thought that "I'm going to perform the design and give it to the
customer for free -- just as I might choose to give away hardware to encourage
the sale", then I have no problem.  But if you've fallen into the trap that
it's our responsibility to do the design and EIS is only a programming group,
then you're overlooking am important revenue possibility.  It constantly amazes
us that we (DIGITAL as a whole) undervalue our consulting and integration
capabilities.

Many customers would think nothing of hiring (for real $$$$) consultants to
analyze their business needs, help them design systems, etc., and it's time
we in Digital realize that we're selling ourselves short whenever we start
thinking "I've got to give away this service in order to make the sale."  

	/Marvin -- who'll-get-off-his-soapbox-now

    
    
    
    
    RE: .4
    
    Standard disclaimer:
    I do not know your exact situtation so all that follows is opinion.
    
    First, EIS and the estimating team should NOT be aggressive in their
    estimate of their perception of what it will COST to the the job, NOR
    in their setting of the PRICE to charge -- EIS should be accurate,
    which is hard to do, but must be the goal.  Sales should make a
    business decision -- and not at the level of the rep who is
    individually goaled to generate revenue and not profits -- as to
    whether, given a EIS price quotation, they should allowance the price for
    other salient business reasons. (the overused phrase "strategic
    investment" comes to mind here....)
    
    Second, both parties must play fair, a large challenge in a stovepipe
    organization. EIS must not pad their estimate knowing Sales is going
    to lower whatever price they provide to make the sale (and their
    numbers); and equally, Sales must understand that what they sell, EIS
    is responsible for delivering profitably -- something they cannot do if
    the project is seriously underbid. The two groups must talk together
    and be managed as a team for the good of the company.
    
    Third. I have enormous sympathy for you in two areas. One, I can
    believe, but not accept, that the EIS DM was unable to give you his/her
    reasons for doubling the quotation. If it was a valid price increase,
    it is defensible and should be explained; if it is political bs, gather
    your allies around you and nuke the parties in question. Second -- my
    this is highly numeric little note isn't it? -- I have seen an
    over-priced bid or two in my time (ahem, ahem) and offer the following
    explanations:
    
    The DM is already in the profitability hole on other projects and is
    padding this one to get some margin $'s back in the kitty.
    
    Historically, some districts have done a p-poor job of estimating
    previous projects and are overly-cautious.
    
    Few districts (I can only think of a handful from personal experience)
    have the people or the tools or the process to do accurate software
    development project estimates.
    
    Anyone who has gone through the Digital software project estimating
    methodology in either its old or new formats knowns that sucker is
    loaded with double dipping for time and fraught with methodological
    pitfalls. 
    
    There are others, but enough is enough. Remember, though, my experience
    has been fault lies on both sides of the fence and only someone willing
    to manage and take responsibility for BOTH sides of the equation,
    REVENUE and PROFITABILITY, should be the final arbitrator.
    
    yours from either side of the fence,
    
    johnb

    Let me first apologize if I have offended anyone in EIS.  That was not
    my intent and I realize that I was unfair with some adjectives
    (outrageous, bloated etc.).  I also know better than to make very broad
    generalizations as I did in .4.
    
    I think that the responses have been excellent especially .5 and .9. 
    I am frustrated because it seems as though we are not as big a presence
    in EIS business as we can be.  I really think that it is tough to sell
    EIS business if you don't have control over the price.  I hope that we
    can try to resolve this difficult issue.
    
    Thanks,
    
    Steve

 
	I got this from a friend. Have fun.
  
	Once upon a time, in a kingdom not far from here, a king
	summoned two of his advisors for a test.  He showed them both a
	shiny metal box with two slots in the top, a control knob, and
	a lever.  "What do you think this is?"
 
	One advisor, an engineer, answered first. "It is a toaster," he
	said.  The king asked, "How would you design an embedded
	computer for it?" The engineer replied, "Using a four-bit
	microcontroller, I would write a simple program that reads the
	darkness knob and quantizes its position to one of 16 shades of
	darkness, from snow white to coal black. The program would use
	that darkness level as the index to a 16-element table of
	initial timer values.  Then it would turn on the heating
	elements and start the timer with the initial value selected
	from the table.  At the end of the time delay, it would turn
	off the heat and pop up the toast.  Come back next week, and
	I'll show you a working prototype."
 
	The second advisor, a computer scientist, immediately
	recognized the danger of such short-sighted thinking.  He said,
	"Toasters don't just turn bread into toast, they are also used
	to warm frozen waffles.  What you see before you is really a
	breakfast food cooker.  As the subjects of your kingdom become
	more sophisticated, they will demand more capabilities.  They
	will need a breakfast food cooker that can also cook sausage,
	fry bacon, and make scrambled eggs.  A toaster that only makes
	toast will soon be obsolete.  If we don't look to the future,
	we will have to completely redesign the toaster in just a few
	years."
 
	"With this in mind, we can formulate a more intelligent
	solution to the problem.  First, create a class of breakfast
	foods. Specialize this class into subclasses: grains, pork, and
	poultry.  The specialization process should be repeated with
	grains divided into toast, muffins, pancakes, and waffles; pork
	divided into sausage, links, and bacon; and poultry divided
	into scrambled eggs, hard-boiled eggs, poached eggs, fried
	eggs, and various omelet classes."
 
	"The ham and cheese omelet class is worth special attention
	because it must inherit characteristics from the pork, dairy,
	and poultry classes.  Thus, we see that the problem cannot be
	properly solved without multiple inheritance.  At run time, the
	program must create the proper object and send a message to the
	object that says, 'Cook yourself.'  The semantics of this
	message depend, of course, on the kind of object, so they have
	a different meaning to a piece of toast than to scrambled
	eggs."
 
	"Reviewing the process so far, we see that the analysis phase
	has revealed that the primary requirement is to cook any kind
	of breakfast food.  In the design phase, we have discovered
	some derived requirements.  Specifically, we need an
	object-oriented language with multiple inheritance.  Of course,
	users don't want the eggs to get cold while the bacon is
	frying, so concurrent processing is required, too."
 
	"We must not forget the user interface.  The lever that lowers
	the food lacks versatility, and the darkness knob is
	confusing.  Users won't buy the product unless it has a
	user-friendly, graphical interface.  When the breakfast cooker
	is plugged in, users should see a cowboy boot on the screen.
	Users click on it, and the message 'Booting UNIX v. 8.3'
	appears on the screen. (UNIX 8.3 should be out by the time the
	product gets to the market.)  Users can pull down a menu and
	click on the foods they want to cook."
 
	"Having made the wise decision of specifying the software first
	in the design phase, all that remains is to pick an adequate
	hardware platform for the implementation phase.  An Intel 80386
	with 8MB of memory, a 30MB hard disk, and a VGA monitor should
	be sufficient.  If you select a multitasking, object oriented
	language that supports multiple inheritance and has a built-in
	GUI, writing the program will be a snap.  (Imagine the
	difficulty we would have had if we had foolishly allowed a
	hardware-first design strategy to lock us into a four-bit
	microcontroller!)."
 
	The king had the computer scientist thrown in the moat, and
	they all lived happily ever after.

	... before 11 replies, as I would have asked you to also start a 
discussion in YUPPIE::PSS, which is REALLY titled "EIS DELIVERY ISSUES". 
Comments on estimating, or methodology might generate a good discussion there. 
Some grizzeled "warriors" still participate there! :>)

	I've been in SWS/EIS for 14+ years, and I have seen all the extremes 
of project results.  Most of the flamers have been the result of HURRIED 
planning efforts, or planning to price, not quality.  I agree with the earlier 
reply that EIS needs to leave pricing to the DM's/Account managers/etc, and 
tell them honestly what resources it takes to do the job, including 
risk/contingency.  Then get their agreement IN WRITING to that plan!  Then,
the Project Manager lives with COSTS, the others with PROFIT! 

	I don't know what drove that DM to raise the price, either, unless it 
was to recover the cost of the "giveaways".  Was this in the "old" days, when 
SWS had Sales Support and Delivery expenses? I will commend the author of that 
note for good methodolgy, anyway.  Oh, and possibly was the initial price 
"leaked" to the customer BEFORE the DM approved????

RE .4:
    
    Are you REALLY sure you want to resurrect this old holy war?
    
>I have found that our local 
>EIS organization consistently overbids (too many hours) every potential project 
>that we propose.  These padded bids are made more difficult to sell because 
>the large majority of hours are at $140/hour.  
    
    Boy does this sound familiar!  From the other side of the aisle we see
    the massively underbid estimates produced by Sales Support that may be
    easy to sell, but are impossible to deliver.  Examples?  Sure:
    
    1.  "Simple" system to implement a data entry system: SS estimate - 410
    hours - PSS estimate from an 8-year veteran of running a half dozen
    projects 4200 hours - yup a factor of 10.
    
    2.  Conversion project of something over 300,000 lines - SS estimate
    1900 hours.  EIS estimate - 3990 hours.  
    
    3.  And of course the project I'm currently leading (another data entry
    system) - didn't even see them until 2 months into the project - 2
    HOURS to implement an 8-part, multi-level, control break report in
    RALLY, 6 HOURS for a data entry application with Rdb database - 6
    HOURS!  18 hours for a multi-level, multi-form data entry application. 
    To date, the actual implementation appears to be running somewhere
    between 8X and 12X of the estimates.
    
    Its a two-way street.
    
    
    I figure a part of my job is to try to give estimates of the actual
    time I figure it will take to do a job.  If my estimate is inexact
    (which it typically is when early in the cycle) I provide a range. 
    BUT, the desire to sell the effort cheap DOESN'T CHANGE THE NUMBER.  
    
    As I heard one of those 3rd party Consulting folks referred to elsewhere
    in this note tell a customer when she threw a fit at what was perceieved
    to be an inflated estimate:
    
        Our job is to estimate how many hours it will take to do the job.  
        Your management's is to decide whether or not to buy it.   Whether 
        or not you like the estimate doesn't change the hours.
    
    
    I also like the often recently heard threat to "go out and find some
    3rd party body shop that has cheaper rates"...  Then the same people
    that bring up this ultimate save-a-penny, short-term thinking &*#@$@#$, 
    complain about "short-term" thinking by other groups!
    
    re .9:
    
    >Sales should make a business decision -- and not at the level of the
    >rep who is individually goaled to generate revenue and not profits --
    >as to whether, given a EIS price quotation, they should allowance the
    >price for other salient business reasons. 
    
    This is something I've seen done.  Our estimate was $140,000.  Customer
    wanted it for $68,000.  Sales sold it to them for $68,000 and covered the
    difference to SWS so they could sell 27 hardware systems...
    
    Just last week I watched an EIS manager (YES AN EIS MANAGER) offer to
    sell a solution to a customer for HALF of the estimated price to try
    and create an environment where we would get additional future business
    from the customer.
    
    Its a two-way street.
    
    >I really think that it is tough to sell EIS business if you don't have
    >control over the price.  I hope that we can try to resolve this
    >difficult issue.
    
    I spent 5 months earlier this year implementing an interface between
    VAX and IBM systems that the customer didn't pay nickel one for our
    time.  Personally, I don't have a problem with Sales or somebody else
    controlling the PRICE.  If EIS estimates 1000 hours and you want to
    sell it for $1000 thats fine with me.  But, the hours don't change.  Of
    course the EIS managers that have the overwhelming goal to generate
    revenue may disagree.
    

    Re: previous reply
    
    Comments like "other side of the aisle"  "it's a two-way
    street" etc. smack of "them and us" mentality.  Aren't you
    folks (Sales, Support, EIS) a team? Shouldn't you all sit together
    and work these things out together - understand each others views
    and problems, work the issues together, come up with the best
    business deal for Digital and the best deal for the customer.
    
    d
    
    

re: .14

It seems that way because you have 2 different groups with 2 different goals.
The sales person is trying to make his CERTS goals.  The EIS person is trying
to show a profit.  I thought this was the kind of conflicting goals situation
that was supposed to be resolved by the Account Manager.

Bob

    re: the last few notes
    
    The District Sales Manager has direct control over hardware/software
    pricing by giving allowances.  He can only INFLUENCE how EIS,
    Educational Svcs., & Customer Svcs. price their services.  It's a
    battle & a pain in the a** to "sell" these other organization on why
    they should lower their prices.  It's often much easier to get an
    allowance against the hardware/software to offset the high cost of
    services.  It saves time, effort, and it closes a sale.  This is one 
    reason why services are so profitable, because they've been 
    subsidized by product sales.
    
    I believe in selling "Total" solutions, but the current system makes it
    an unpleasant task.  I believe either the Corporate Account Manager, or
    the District Sales Manager, should have DIRECT control over ALL
    pricing.  This way, if I have to get a lower price, I only have to 
    convince one person, instead of the four or five people today.
    

    I think there are a couple of definitions that should be made clear to
    help understand the posible 'conflicting' goals issue.
    
    CERTS - Sales is measured on certs.  This is not really revenue.  For
    example: a sales person sells (gets the PO) a consulting project for $2M
    in June (last month of the fiscal year).  This allows the sales person
    to make their budget.  It is unlikely that Digital will actually accrue
    the revenue before the end of the fiscal year.  It is not uncommon on
    long projects that the revenue is actually accumulated over multiple
    fiscal years.
    
    REVENUE - This is actual $ brought in to Digital by invoicing customers
    for products/services delivered.
    
    PROFIT (MARGIN) - This is the difference between the revenue for a
    product/service and its cost.  This is potentially very difficult to
    measure.  Production of the product or the cost to deliver the service
    can be well quantified, but it is not so easy to quantify some other
    items like the cost of selling the product/service.  How much time was
    spent by sales, sales support, management... in trying to convince this
    customer to buy said product/service.
    
    The services organizations are measured on both revenue and margin
    (revenue - cost of delivery).  For a sales organization measured on 
    certs this possibly represents a conflicting goal.  As I mentioned 
    earlier this is in the process of changing.  Sales will soon be measured 
    on margin (profits), and the cost of selling will be tracked and 
    included in the computation of their performance.  I think this will 
    result in a a lot less goal 'conflict' with the services organizations. 
    My observation so far is that profit as a metric is starting to change 
    the mind sets of the sales people that have to live with it.
    
    
    Peter Dillard
                                                               

    This is the Digital notesfile on the Digital Way of Working and not the
    PSS notesfile as pointed out by .10(?) so rather than shoot down the
    rat hole of estimating practices and methodologies lets talk about the
    organizational structure and people.
    
    Has anyone noticed we have all of these organizations -- EIS and Sales
    with sales supporting swinging between them over the years, 
    Corporate accounts, CSS, CS and Ed Services? Now I know that there has
    been a lot of movement (as well as lip-service) to the notion of
    driving P&L and control down to the Sales DM and even unit manager
    level, but is that enough (regardless of whether or not it is
    working!)?  To truly provide total business solutions to our major
    customers why don't we build dedicated account teams and abolish all,
    repeat all other functional service organizations?
    
    For each of our corporate accounts, give that account one, repeat, one
    team leader -- for the big ones, make it a VP level appointment. That
    person's responsibility is to make that account satisfied and
    profitable to Digital -- growth should follow, but not be mandated.
    That Digital team leader is responsible for all of the Digital
    service functions (i'm including sales) for that account on both a
    long-term and short-term basis (i.e., this quarter and five years from
    now.) Current organizations such as customer service, EIS delivery, ed
    services, CSS, sales, sales support CEASE TO EXIST and all of the
    people who currently work for those organizations keep doing their same
    job, but within a total account focused team. (I know, logistical
    support for customer service (old field service) must be administrated
    at a country/world-wide level and not the account level, but, hey, pass
    that function back to manufacturing and let CS reps concentrate on
    accurate forecasting of their spare part needs on an account basis. All
    other organizations with similar cross acount functions are treated the
    same way -- give those functions back to some other non-account focused
    group such as Mfg, Eng, Admin, Finance etc.)
    
    Now why do this?  Well, now, let me count the ways..
    
    Break down the stovepipes once and for all between all field
    organizations. Turf fighting and protection in the field will continue
    as long as one group (i.e., sales) appears to be winning over the
    others. Team building can only be fostered in an environment where
    vertical lines of authority, metrics and goals are not drawn between
    functional groups. Every person on the team should be identified not
    by a label such as sales or sales support but as, for instance, GE Customer
    Support Team Member (hell of a title, eh?).
    
    Eliminate the perennial complaint of our customers that we are hard to
    do business with by providing a focal point to the customer.
    
    By providing a single point of focus to the account, tailor the
    presentation of all services and hardware/software to that account in
    such a way as to maintain both high customer satisfaction and overall
    profitability for Digital. Some customers want the best hardware price,
    other will pay top $ for hardware, but need lower maintenance $, or
    lower service costs. With a business manager watching the mix per
    account we will offer flexibility of product/pricing mix to our
    customers and they will love it!
    
    The major obstacle to this scenario, I believe, is the quality of the
    woman or man who is this customer team manager. One would need a
    professional manager with a deep understanding of digital and the
    customer of the quality that one would be willing to bet the companies
    future on that manager. And you'd need a lot of them. I've met very few
    business managers of this caliber at Digital -- but then again, I may
    not be moving in the right circles.
    
    So hows that for an extended lunch hour fantasy of what I'd do if I ran
    the company!
    
    regards,
    
    johnb
    
    

    agree with .18 except for the VP as account mgr part.
    
    
    Scooter

    I didn't say pick a current VP :-}
    
    Actually, the point of saying a VP has more to do with recognizing the
    size of the responsibility and requisite authority necessary to bang
    the proper heads about. If this individual is the representative of
    digital to a corporate account that generates $500 million US /year,
    he/she had better have a title that'll stand up to calling high!
    
    johnb

 Re: .18
 
 Excellent!  I really agree that the stovepipe organizations are the root of
 many of our difficulties.  As customers demand total integrated solutions,
 we need to be organized in a way that fosters the delivery of total integrated
 solutions.  The suggestions made to eliminate the separate groups with 
 conflicting goals are right on target.  I would also hope that in the end,
 the goals of the individual teams would include revenues and profitability.
 A key to our success should be to balance the need to increase revenues with
 the need to be profitable.

 Of course, these things always seem easier to talk about than to implement. 
 I really hope that somewhere down the line, we move toward this type of 
 structure rather than trying everything else short of this. 

 Steve   

    It's clear that "stovepiped" organizations are a problem.  This
    is something that almost all businesses seem to be discovering
    now.  Engineering does not talk to manufacturing.  Marketing doesn't talk
    to sales.  Sales doesn't talk to services. But the answer is not
    necessarily a reorg.   Behaviour has to change. The answer is cross
    functional teaming.  All of us - no matter what organization we "belong"
    to - have a single purpose: do what's right for the customer and whats
    right for Digital.  We can only accomplish this when we form teams
    that cut across our provincial, stovepiped, artificial structures.
    
    d

    I suspect that at least part of this suggestion will occur over the
    next few years or sooner.  I believe there will be dedicated account 
    teams.  I believe there will be a single service organization.  There 
    are some reasons to keep a separate, or at least partially separate, 
    services organization.  For example, a team could not afford full-time 
    support of a consultant who specialized in a particular technology or
    application that might be necessary to the total solution, but only 
    for a couple months or a year.  There will always be some kinds of 
    support that would best be shared across accounts and other kinds of
    support that would best be dedicated to an account.

    >>                                          But the answer is not
    >>necessarily a reorg.   Behaviour has to change. The answer is cross
    >>functional teaming.  
    
    I agree cross functional teaming is it; that is the essence of my
    suggestion! I also agree that "behavior has to change". I will add that
    I am as tired/amused/cynical about "reorgs" as the next digitoid. The
    remaining issue, however, is can we bring about a change in behavior,
    cross-functional teaming, et. al. __without__ changing the
    underlying/over-riding organizational structures which encourage
    vertical empire building and vertical metrics? 
    
    And for those of you who might think these customer account teams
    would develop into empire building units of their own, I applaud your
    perceptiveness of human and organization behavior, agree it would
    happen, and in time need a re-org to fix it (but give it a least 5
    years, please).  However, given the current situation, I submit that
    people building empires whose primary focus is to integrated all the
    multi-faceted talents and services of this wonderful company into a
    unified whole for the good of our customers and profitability of
    ourselves, is better than the current arrangement.
    
    thanks to those of you who have taken the time to say kind words. I'm
    still waiting for the other shoe to drop....:-]
    
    johnb

    Except the one biggest roadblock to empire building would be metrics by
    profit.  If the team is generating enough business to support an empire
    and then some, so be it.

	... I made a friendly bet with a manager in my District that an 
organization similar to JohnB's description would be established by FY92.  I 
don't think I'll be far off! :>)

    This is, more or less, the structure being taught in the EIS Corporate
    Training (MTT) organization.  We are headed towards the scenarios
    being described.  This may be a US structure, but work is currently
    underway to make all geographies look similar, subject to local
    requirements.
    
    The Account Manager -- is responsible for profit (not certs or revenue)
    in the Account.  S/he is helped by the Account Team, which may include
    an Account Integration Executive (a business/technical person), an
    mangement consultant, and/or others who can contribute to the account
    being profitable.  The Account Manager is responsible for developing an
    Account Plan, which describes how DEC will work within the account to
    generate profit.  Each business opportunity goes through a
    qualification process during which a decision is made on whether or not
    to pursue any specific piece of business. An Account Manager and team
    is which is on the ball is working with the client extremely early in
    the process (by selling consulting services, if possible) so that DEC
    can influence any RFPs which are developed.   This leads to an
    extremely long selling cycle.  There is one program that we have been
    working for something like 15 months, and the RFP is just coming out.
    
    The Program Manager -- is responsible for the profit on one particular
    program.  S/he assembles a cross-functional team to deliver a total
    solution to the customer within a specific account.  When the PM gets
    involved varies, depending on a variety of issues, but may start as
    soon as an opportunity is identified.  The earlier the better.   The
    catch here is that the PM must be able to deliver what the client has
    been sold.  This requires that there is agreement between the PM and
    Account Manager/team about what is being sold and for how much -- no
    services give aways in this structure.  
    
    The Sales DM, EIS DM, CS DM, and DCC DM are responsible for
    profitability in their respective domains. 
    
    These folks are the ones to whom the AM presents the opportunity, the
    PM presents the proposal, progress reviews, change plans, etc.  They
    provide approvals/rejections as a team, based on their own unique
    perspectives.   If Sales, then, wants to discount or allowance
    hardware, the EIS folks can make sure that the total costs of the
    service being provided (with appropriate margin) is still intact. 
    Total profitability is what we are after here.
    
    The result of all of this is that cross functional cooperation is
    required is anyone is to succeed.  
    
    Zereski, by the way, is resposible for the profit on all stuff that
    happens in the US, Gullotti for all EIS stuff, world wide, Ray Wood for
    all EIS stuff in the US, etc.  
    
    Finally, there are what we call Executive Partners, which are VP (and
    higher) level executives who are assiged to each of the named accounts
    (I think).  Even Ken participates in the program.   
    
    
    There are a couple of other things:
    
    First, we don't give things away anymore -- consulting, software,
    support, etc.  Our profit is in our services, not our hardware (for the
    most part).
    Second, we say no when customers ask us to make changes or we ask for
    money to pay for them.
    Third, we are all working for profit, period.  
    
    The field says we have a way to go before everything works this way,
    but we are moving towards this.  How long it will take will, for the
    most part, be a function of how well we learn to work together, bury
    old issues, and burn down the stovepipes.
    
    If yor are interested in more info, there are a couple of course,
    Digital Systems Integration Overview,  The SI Qualification Workshop, 
    an introduction to Value Based Pricing, and a set of Program and
    Project Manger courses, along with a Executive Consulting Program.  Let
    me know if you want more info
    
    LI
    

    Re: .26 

    > ... I made a friendly bet with a manager in my District that  an
    > organization similar to JohnB's description would be established
    > by FY92. I don't think I'll be far off! :>)

    Actually, you may be late!

    Re: a couple further back

    I'll second the notion of having "shared" consulting  resources.
    Most major accounts have a very wide variety of technologies and
    some extremely  knowledgeable  people   asking   very   detailed
    questions.  Having  a  person  who  knows  VMS internals, Ultrix
    internals, everything  you  ever  wanted  to  know  about  every
    network  product/technology, plus all those layered products, is
    way too costly for your average corporate  account  (except  for
    maybe  DuPont  and a couple others). This is where the notion of
    having a geographical district providing resources to Sales on a
    "contract" basis makes a lot of sense.

    d

	The only thing I don't agree with in your senario is the role of the
current geographic management structure.  I believe that we will eventually
have EVERYTHING as account management teams, not just the big commercial or
Federal boys.  You could have, for instance, a "Georgia State Government" Ac-
count Manager, or even a "Southeastern Regional Manufacturing" Account Man-
ager", each with authorities described by Larry.  You say the AM is not re-
sponsible for "certs or revenue", but if they are to make the profit part,
those two have to also be in their domain.  I don't believe a strong AM can
work with that many people second-guessing them.

	What does this leave the traditional DM?  Mentoring, teaching,
training plans, perhaps even getting out in the accounts for management
consulting.  Perhaps they will become, in a role sense, as the Big-5/6
partners.  Too bad the money won't be there ...

		or will it?? :>)

	Time will tell!

>................................................  You say the AM is not re-
>sponsible for "certs or revenue", but if they are to make the profit part,
>those two have to also be in their domain.  I don't believe a strong AM can
>work with that many people second-guessing them.

re: .30

I interpreted that statement to mean that the AM is not MEASURED on on  "certs
or revenue", but rather on overall profit.  The sentence makes sense in that
context.

Bob

    RE: .28
    
    Actually, I am aware of this semi-official strategy as I sit in a DCC
    which has been instrumental (I think) in moving the company in this
    direction. Indeed, my scenario is an extension of the one you outlined.
    What follows are my "nits", unorganized alas, which I hope will make
    clear why I took the more extreme position -- however unrealistically.
    
    >>The Account Manager 
    
    The lingering use of sales terms reflects the mistaken belief that the
    sales organization as currently constituted should provide the business
    leadership on an account team. I am not at all sure that given the
    history of relationships between the stovepipes at Digital that this is
    going to work; I am not al all sure that given the nature of the sales
    force personnel hired into Digital that this is going to work. (This
    may be taken as sales bashing, and to some degree it is; but the issue
    is not that they are good at selling, a noble skill, but whether or not
    they are good at business management, an equally noble skill, and more
    pertinent to leading a Customer Team.(Please note change of term to
    reflect focus!))
    
    >>The Program Manager -- is responsible for the profit on one particular
    >>program.  S/he assembles a cross-functional team to deliver a total
    
    Stovepipes again. Or am I the only one to notice your scenario has an
    account manager (Sales) with admittedly an expanded role (profitability
    v. certs) and a program manager (EIS), a person whose functional
    exsistence is half way between a glorified project manager and delivery
    unit manager! In the same paragraph you even say the same catch still
    exists: "The catch here is that the PM must be able to deliver what the
    client has been sold.  This requires that there is agreement between
    the PM and Account Manager/team about what is being sold and for how
    much."  The issue is not really one of service giveaways, it is
    sequential pricing from sales cutting a deal, to the DCC consultants
    doing their pricing (should they have a revenue opportunity at all), EIS
    delivery demanding its price, Customer Service.... etc.
    
    >>The Sales DM, EIS DM, CS DM, and DCC DM are responsible for
    >>profitability in their respective domains. 
    
    DMs in their respective domains. oh lord. Do you not see that that is
    precisely the structure I propose eliminating?  There is an historical
    inertia in these stovepipes which makes teaming hard to do -- I know. I
    have worked in delivery, sales support, the old SIC, and now a DCC and
    when one tries to get a cross-functional team together when doing a
    proposal or a project, there is resistance every step of the way. It is
    a fact of human nature, rightly or wrongly, that you work with the
    people you know, your teammates, colleagues and buddies to get the job
    done. (this is probably a note in an of itself and I can't do it
    justice here)
    
    More importantly, are you truly expecting to get all those DMs together
    to review all opportunities as they occur? Are all current account
    review sessions going to be attended by all of these sr mgrs? Why not
    go the logical step, eliminate all of these DMs -- several notes in
    this file have made the point we have too much middle management anyway
    -- create the customer team leader and give him or her the final say
    over what the mix of hardware/software/services is with whatever total
    profitability guidelines are desired by the corporation. If you do not
    do this, you still have institutional boundaries between the functions
    and no amount of team building can overcome those organizational
    fences.
    
    >>Zereski, by the way, is resposible for the profit on all stuff that
    >>happens in the US, Gullotti for all EIS stuff, world wide, Ray Wood for
    >>all EIS stuff in the US, etc.  
    
    Is it not one of Ken's (and the executive committee's) stated goals to
    push that resposibility down to the level where it should be managed --
    the account level.  The metrics must be in place down in the trenches;
    the authority to deliver profitable business must be down in the
    trenches; Zereski, Gullotti, Ray Wood, et al should come to work
    everyday knowing that everyone of their reports and everyone of their
    report's reports should be doing profitable business. Its too damn late
    when it gets to their level to figure out if the company made any
    money!
    
    >>Finally, there are what we call Executive Partners, which are VP (and
    >>higher) level executives who are assiged to each of the named accounts
    >>(I think).  Even Ken participates in the program.   
    
    Yes and don't they close a lot of business? (only mild sarcasm,
    really.) The whole concept of the EPs arose when it became obvious that
    IBM had the ability to call higher in the account than we did. It was
    believed, and is to some extent true, that providing a senior
    level Digital executive as a partner to our major accounts would help
    alleviate the problem. I believe it has worked well in some situations.
    It does not alleviate the situtation however, that a local IBM branch
    manager has access farther up the chain of a customer than any Digital
    DM I've ever met! (rathole alert, rathole alert)
    
    >>but we are moving towards this.  How long it will take will, for the
    >>most part, be a function of how well we learn to work together, bury
    >>old issues, and burn down the stovepipes.
    
    First, let me say I'm sorry if any part of the above diatribe came on
    too strong. I've been reading notes for years, now, without writing or
    replying (despite some fairly obviously strongly-held opinions!) and
    answered this one in a spare moment. the dam has burst and YOU've been
    caught in the deluge :-]].  
    
    Second, the excerpt above sums up both of our positions really. WE
    share the same goals and have a difference of opinion as to how to
    achieve them. I strongly believe (you may have noticed) that as long as
    the institutions exist, it will not be possible to eliminate the
    stovepipe mentality. Realistically, is it possible for Digital, the
    ultimate consensus company, to totally restructure the field
    organizations into our joint goal of a stovepipeless (ugly neologism
    isn't it) organization? don't know. Would sure like to try though.
    
    I gotta get back to work!
    regards,
    
    johnb
    

    There seems to be a strong inclination in this discussion to
    assign "ownership" to someone or some organization.  This is
    gets you back to the stovepipe syndrome.  Ultimately the "owner"
    will try to please whowever signs his/her review.  The TEAM
    should own the problem, work it out, and come up with the right
    solution.  No individual can do that.  Its a cross functional,
    collaborative task.
    
    When the team dynamics work everyone wins: Digital gets
    the sale, Digital makes a profit, Account Managers meet their
    goals, EIS gets manageable business...  
    
    d
    

re: .33

But then you get back to managment by committee and no one with responsibility/
accountability for decisions.

Bob

    A problem with the scenario in .18 comes from the size of many
    corporate accounts.  I work in a district that is mainly composed of
    corporate accounts and only one of those generates enough business to
    support a team that 'might' allow it to function without shared resources.
    
    As you create the shared resource pool you create the need for 'local'
    management of that pool.  The shift of that pool to industry instead of
    geographic focus has produced some benefits for our customers, but my
    observation has been that the expense and personal disruption of
    extended travel limits the usefulness of resources out of the required
    geography.
    
    For those customers that do produce large amounts of business (which
    account generates that $500M???) that can support our efforts I think
    your model is a good one.
    
    Peter Dillard
                                                                    

    At the risk of being run over by the parade ...
        
    I believe that there are several flaws in the Account Management model
    being proposed.
        
    1) Remote management.  Most of our large accounts are dispersed over a 
       large geography, therefore the "account team" is also geographically 
       dispersed.  The result is that very few team members are co-located 
       with the team or account manager.  This makes coaching, counseling, 
       teaching, training, disciplining, etc. difficult and infrequent.  
       Even performance reviews are more difficult when the performance is 
       viewed from afar.
        
    2) High cost of sales.  While it may still be possible for each account 
       team to show a "profit", this business model implicitly defines a 
       higher cost of sales than a geographic-based model.  How many sales 
       people will have to travel to "Nowheresville" to make sales calls?  
       One for the bank, one for the city/county government, one for the 
       hospital, one for the manufacturer, etc.  Therefore, even though 
       each account team may show a "profit", the total selling costs to 
       Digital are higher.  The same holds true for account-based support 
       costs as well.
        
    3) Extreme shortsightedness.  Measurements influence behavior, and by 
       focusing on "profitability" as the key measurement, each decision 
       will be influenced by its impact on this Quarter's/Year's profit.  
       Investments in time, money, training, personnel will be forced to 
       show a very near term payback. (The future will be someone else's 
       concern.)
        
    4) Under-funded support resources.  Each account team will staff with 
       the minimum appropriate mix of sales and support skills, based on 
       the account plan.  Additional skills that cannot be justified on a 
       full-time basis as members of the account team, will be forecast at 
       the beginning of the year and paid for as used.  However, projects 
       are always uncovered during the course of a year that were not 
       previously forecast.  The skills necessary to pursue these new 
       opportunities will quite likely be unavailable because they were not 
       funded.  Further, the use of any skills outside the immediate 
       account team will be discouraged because of the expense incurred 
       when they are used.
    
    5) Does not emphasize expansion of customer base.  An account-based 
       model is implicitly focused on its existing customer base.  Account 
       teams are formed around customers with significant current revenue 
       streams and future potential.  The primary thrust of the account 
       management model is to increase the revenues derived from these 
       accounts while reducing the costs.  This strategy does not promote 
       the expansion of our customer base.  Persons not associated with a 
       large installed account may be assigned to new business development 
       units, but this is not the mainstream.  These persons are like 
       second-class citizens.  And our account-based marketing programs do 
       not support their activities.
     
    6) Limits career progression.  Because we are shrinking our pool of 
       support resources, and not adding to our customer base, there will 
       be very little opportunity for career progression.  If you're not 
       adding new accounts, you don't need new account managers and team 
       members.  The only openings will be created by retirements and 
       departures (voluntary or otherwise).  In a company as young as 
       Digital, in an industry as pressured as the current computer 
       industry, there won't be many openings for advancement created by 
       either method.
    
    By following the proposed Account Management model, it MAY be possible 
    for Digital to make a profit (survive) for many years with stagnant or 
    shrinking revenues generated by a shrinking customer base.  I might 
    recommend portions of this strategy to a company like Unisys, but 
    hopefully not Digital.
    
    I much prefer a strategy for Digital that promotes expansion of our 
    customer base and creates new opportunities for career progression.
    
    Regards,
    Don

    With Digital's current sales organization, which consists of weak
    managers, ie. puny people compared to the highly skilled and confident
    managers at IBM and some other computer sales organizations, it will
    never succeed at selling EIS. 

>    added value Digital brings to the table.  If done right, EIS projects
>    can contribute big margins to Digital (and are, in many places.)  Add
>    to this things like Assets packages (which cost Digital next-to-nothing

I doubted! at least for the time being, I don't see EIS is contributing to 
get in high margin, as it doesn't reduce redundancy.  It actually create 
another level of management.  Time and effort are wasted in providing 
reports, explanations and justification.  The duration of 'time to market' is 
longer and the cost is higher to get a job done.

>    EIS is here to stay in some form or another.  The recent merger of 
>    EIS and Customer Services (formerly field service) at the corporate 
>    level suggests the ultimate move to a single services organization.  

I agree this might be a better structure, but as long as the matrix system 
exists for different functions then EIS won't work.  Unless we follow IBM, 
services don't really need to care about the pricing, margins.  Only the 
Sales care about it.  Services only providing support and become a expenses 
cost centers.

I agree with .4, EIS is hard to sell, especailly in Digital. It is getting
more and more difficult to do business internally in Digital then to do
business with our customers.  Currently, the EIS managers need to manage
the four functions but they don't really know the business in the different 
functions.  I have a observation that at least 85% of the EIS managers
are from SWS.  Can I say that, at least for now, EIS = SWS?  And within
'EISMC',  75% of the members are from SWS.  So during the meetings, 80 -
85% of the time are talking about SWS issues.  Is it s process, or Digital
would like to learn it from the hard way. 


>    It's clear that "stovepiped" organizations are a problem.  This
>    is something that almost all businesses seem to be discovering
>    now.  Engineering does not talk to manufacturing.  Marketing doesn't talk
>    to sales.  Sales doesn't talk to services. But the answer is not
>    necessarily a reorg.   Behaviour has to change. The answer is cross
>    functional teaming.  All of us - no matter what organization we "belong"
>    to - have a single purpose: do what's right for the customer and whats
>    right for Digital.  We can only accomplish this when we form teams
>    that cut across our provincial, stovepiped, artificial structures.
    
I totally agree with this, cross functions team work can provide a total
solution for the customer, not necessarily a reorganization.  Reorganization 
needs investment.  The reason why Digital face such a steep downturn is 
partly because of the EIS reorg.  I hope the VPs well understand what they 
are doing, otherwise, Digital will become IBM or become a Japanese company.

    re: .36 and .38  ... talking about EIS and cross-functional teams ...
    
    Cross-functional teams will be the tar pits that snuff out any
    remaining life we have in the old dinosaur we call EIS.  Everyone
    sees these teams as the answer to "stovepipes" and "empires", but
    they are a horrendous overhead to support, and we gain little in the
    process.  A team has to have one leader and a goal;  whereas most of
    the teams I've seen have had neither.  Unless the individual managers
    of the team members assign authority to a team leader, the cross- 
    functional team is nothing more than a very expensive and inefficient
    method of communication between real organizations.  So much so, that
    software and integration services in our current model will become
    so expensive that we will price ourselves right out of the market.
    
    It will not be because of high technical salaries, or of high R&D
    costs, or of time-to-market issues.  It will be our overhead costs
    associated with rooms full of cross-functional managers squabbling
    over who gets to "recognize" what revenue for what services.
    
    Right now I'm in the middle of a program where the cross-functional
    management "team" has spent 90 percent of it's meeting time arguing
    over internal financial issues and maybe 10 percent trying to figure
    out how to deliver something to the customer.  The final result has
    been not far short of disaster, both in terms of quality and economy.
    The customer is no slouch on negotiating, so I believe that before all
    is said and done, the customer *will* get something delivered, and he
    *will* get quite a bit of his money back to make up for our blunders.
    
    It was a humiliating experience to be at the customer site when the
    senior VP was walking out the door one night.  He began to smile and
    say goodnight to me, then he noticed the Digital badge.  The look I
    got after that made me believe he was thinking of having Security run
    me out of the building ...
    
    EIS and Digital both have a long way to go before they will be able to
    compete and survive in the changing computer industry.  Reductions in
    management overhead and elimination of competing organizations are just
    the first steps.  Even with our largest customers, we still have to be
    cost-competitive, and all the garbage about "value-added" services only
    means something if we are *truly* delivering valuable service.  So far,
    I don't think EIS has a distinguished track record at that ... but the
    industry will be the final judge!
    
    Geoff Unland
    

    I'm involved in a program migrating software to a DEC platform and the
    software being sold to a customer. We have a long way to go before we
    can be truly responsive in this kind of multi-party effort. If EIS, with
    an accent on "I"ntegration, is where we want to be, there's a whole lot
    more to do than just bore holes between adjoining stovepipes.

    The frustrating  part is we do know how to work together. We just have
    problems doing it in the normal course of business.

    A tale from my own experience:  A few years ago, I was involved at a
    bank where their central message switch (VAX based) was crashing. My DM
    asked me if I could take a look, since I was one of the few people
    around who knew ancient hardware -- DV11s -- and had a "Peripherals
    Handbook" to look up how the thing worked.

    I said "Sure, George." I got there a day before promised, for a 1:00
    meeting. I walked in, and there is a cast of 20+ people in the room (I
    thought I was meeting with 2 or 3!), already in heated discussion. I
    recognized the field service account manager and rep, but that's about
    it. After a few minutes, I piped up and volunteered a few potential
    scenarios which might be culprits. One of the senior customer VPs glared
    at me and asked me who I was. I introduced myself, told him I'm from
    DEC (scowl deepens), that George sent me, and... the customer launched
    into an extended screaming vehement expletive filled barrage about how
    we weren't responding, that we're incompetent <expletive>s, etc.

    As it happened, I had briefly checked the customer's system before going
    into the meeting. While poking around, someone was packing up a crash
    dump tape to send to one of our field service gurus. Now, George had
    told me that we had been waiting for that tape for a week. So, after a
    couple of minutes of suffering through the withering tirade, I boiled
    over. In six years on the job at DEC, I've only screamed twice. This was
    one. I screamed back, repeating all the same expletives, "If your
    <expletive> crash was so <expletive> <expletive> serious, then why were
    you just sending out the <expletive> tape of the <expletive> crash dump
    we've been waiting for for a whole <expletive> <expletive> <expletive>
    <expletive> week?!?"

    Dead silence. He turned to one of his VPs and, with remarkable self
    control, asked if this was so. A quiet "Yes." With the air cleared, the
    rest of the meeting was much more constructive.

    After about three weeks of insane hours (12-16 hour days and weekends),
    working with the switching system software vendor, field service and
    CSSE (customer systems support engineering), going though fiche, DV11
    prints, making field mods to a UNIBUS trace board, writing programs to
    dump bus mapping registers and interpret all DV11 activity into
    something readable, we found the smoking gun. And we charged a happy Mr.
    Screaming Meemies $45,000.00 for our time because it wasn't a DEC problem.

    The point is, you get to know people pretty well working together with
    them that closely. That's how you break down stove-pipes. It's not a
    question of "putting together" a cross-functional team, like assembling
    a crazy-quilt -- often giving the program manager (if you have one) no
    more than a pointer to where s/he might find owners of cloth scraps,
    metaphorically speaking.

    Teams are people already used to working together. You already have the
    trust and reliance between individuals to make the team work. If you
    have enough of that between enough individuals, voil�: trust and
    reliance between organizations.

    The "account manager" concept tries to formalize that kind of working
    together at a small enough size to build cohesiveness. But the hunt for
    resources still spans too many organizations. And no one is accountable
    for finding the right staff -- except, again, for the program manager,
    stuck with accountability but no authority, who gets their head handed
    to them on a platter every time they put their program in "Red" because
    of resource issues that it's "THEIR JOB" to solve.

    At a local level, we once had two service organizations, district SWS
    and district FS, with area back-up. You knew where to go to for help and
    who was responsible. When we grew we didn't keep what worked. Instead we
    "focused" our approach: added more organizations for technical focus,
    added more organizations for industry focus, added more organizations to
    manage having to deal with more organizations...

          More and more organizations to focus on customers when the
          proliferation of organizations was making us lose focus.

    We need to integrate ourselves far better if we are to succeed in
    helping our customers integrate themselves:

    o  We've implemented account management to be more responsive to a
       customer. What we need is fewer organizations on the DEC side for the
       account manager to manage across on behalf of the customer to be
       really responsive.

    o  We've implemented program management to be more responsive to
       delivering solutions to a customer. What we need is accountability
       and authority vested in single points of contact, not a whole
       organization -- and process -- devoted to managing other DEC
       processes, gaining cross-functional consensus, and engaging in
       general resource-wrangling, all to maintain an adequate level of
       responsiveness in just one area of customer activity.

    I wanted to work on my program because it's the kind of work we should
    be doing and we need to be successful at. And I'm glad I'm doing it.

    I thought I wanted the program manager's job when the program started
    because I knew DEC well enough to pull the pieces together.

    I'm glad somebody's doing it. Right now, I'm glad it's not me.

    /Peters

    re: .39
    
    >>A team has to have one leader and a goal;  whereas most of
    >>the teams I've seen have had neither.  Unless the individual managers
    >>of the team members assign authority to a team leader, the cross- 
    >>functional team is nothing more than a very expensive and inefficient
    >>method of communication between real organizations.  So much so, that
    >>software and integration services in our current model will become
    >>so expensive that we will price ourselves right out of the market.
    
    Well said.  Somewhere back in this discourse I offered my scenario of
    account teams. I've decided after reading through all the replies,
    that the key principle I was trying to articulate was someone must be
    in charge.  And, at Digital, we have taken the matrix organization, the
    consensus management approach out to the field and, for whatever
    reason, I don't think it's working that well.  I have my share of stories
    similar to yours; and know of many more through the grapevine.  We need
    a better way to bring together the multiple organizations that make
    Digital so rich in resources and, as the story told in .40(?) relates,
    so effective in getting the job done ONCE YOU GET THE PROPER PEOPLE
    WORKING ON THE PROBLEM. The steps are clear:
    
    		Problem/Project definition (what do I need to fix the
    						problem/do the job)
    		Resource location (find the right people regardless of
    						organizaton)
    		Priorities of resource allocation (what's hot, what's not)
    	   ->>>>Authority to assign (frequently an unbelievable process!)
    		Delivery of resource (get 'em working)
    		Problem resolution/Project completion
    
    At everyone of those steps there is room for continuous improvement by
    us (and even our customers) in the quality and speed with which we
    respond.  I still maintain, one individual, at either an account or
    geographic level, __in charge__ of an team of field service, eis, CSS,
    sales and sales support people would allow us greater freedom to
    improve the process than the current scenario of different managers,
    with different metrics, goals and ambitions being told to work
    together.
    
    regards,
    
    johnb
   

re .41

You have hit the nail squarely on the head!

Problems that we have solved through account management are those of

 (a) the customer dealing with a multiple-entry-point management matrix
     to solve their issues, and

 (b) people assigned to the account not knowing who is the ultimate authority
     regarding Digital's activities within the account.

As you also stated, though somewhat by implication, we have not solved the
problem of

>>    	   ->>>>Authority to assign (frequently an unbelievable process!)

This is THE problem in the field. I've been in enough field jobs at DEC long
enough as an IC and manager to vouch that there is NO PROCESS for getting a
resource or even a closed-end-date commitment to identify a resource.

By their very definitions and natures,

            "MATRIX MANAGEMENT" OF A "RESOURCE POOL" CANNOT WORK.

We responded better to resource requests in the past because the management
matrix was very small at the field level. Now it's ENORMOUS and we are all
suffering for it, especially those of us in the unenviable position of trying
to get a resource.


/Peters

	... and with regard to getting a resource assigned and committed, 
	it's (obviously?) important to get a person with the right skills,


	and the running line out here is to always remember

		AVAILABILITY IS NOT A SKILL

	Hmmm,  Maybe we need to make that into a sampler to post on
	every manager's wall. 8-)


		*****************************************
		*					*
		*					*
		*	A V A I L A B I L I T Y		*
		*					*
		*					*
		*	    I S     N O T		*
		*					*
		*					*
		*	   A     S K I L L		*
		*					*
		*					*
		*****************************************

Talking about finding the person with the right skill, what about the EPS?  
Can EPS really help us to find the person with the right skill in EIS to 
support pre-sales and post-sales?  Is EPS being fully utilized?

Kevin.

    
    EPS? What is EPS?
    
    EIS has a business system (SBS) with a skills matrix and search
    capability ... it is way more complex than it should be and is thusly
    under utilized. It also doesn't contain anyone not in EIS or sales
    support.
    
    

 EPS is "Expertise Profile System", it was actually used within SWS and is 
now being modified to use in EIS.  There is still a long way to go in order 
to make this system fit for the whole EIS organization.  That's why it is 
now under utilized.

 I am not sure if it is the same with the SBS that you mentioned.


Kevin.    

    re .42 
    
    I'm glad I hit something on the head lately -- makes me feel good!
    I think you in your turn say it quite nicely:
    
>>By their very definitions and natures,

>>            "MATRIX MANAGEMENT" OF A "RESOURCE POOL" CANNOT WORK.
    
    and I'm heartened that you feel that way both as an IC and a manager.
    
    re .43  
    
    Availability is indeed most emphatically not a skill -- I may make that
    my personal name for a while!  Unfortunately, we have conflicting
    issues here which create the problem.  
    
    pressure to reduce/contain the size/cost of support organizations
    
    ever increasing complexity of product set
    
    ineffective technical career paths that lure some of the best out of
    sales support/delivery roles (in the field, I do not speak for
    engineering)
    
    Enormous variety in short term needs. 
    Enormous pressure to respond quickly.
    
    In short, I'm not sure its possible to develop and maintain a sales
    support/delivery team that can cover all the bases. Thus, the ideal
    sales support person is someone with an area of expertise, but most
    importantly, the ability to be a generalist and information broker.  Ya
    gotta know a little about a lot, and ya gotta know where to find out
    more fast!  I made my career in sales support not by knowing a lot about
    something, but being able to handle anything to some degree -- if only
    enough to define the problem well enough to get the right person
    involved!
    
    regards,
    
    johnb

    re .4 & .10
    
    To address the note that seems to have precipitated all this
    interesting discussion with an observation that I don't think has been
    raised.  What you apparently did was provide a fixed price quote for a 
    project.  This immediately raises a red flag to any EIS manager, cause 
    s/he's locked in.  (EIS prefers to have time & material bids.)  You
    probably left (or appeared to leave) no estimate for potential problems,
    which every EIS manager knows will happen (and that kills the profit).
    
    What's the solution?  Well, if you're convinced of the correctness of
    your estimate, sell your customer on it.  Tell them it will be done on
    a time and material basis though.  See if your customer will buy it. 
    If they won't maybe you'll understand EIS's position a little more. 
    Then what?  Well maybe you can mix in some fixed price services that
    EIS will agree to and do the rest as time & materials, share the risk
    so to speak.  Or, talk to your EIC manager.  Your project might help
    generate new business and s/he might be willing to share some of the
    risk.

>> Note 1318.47 by JBEICH::BEICHMAN 
    
    "Availability is indeed most emphatically not a skill ..."
*************
	Yes, but the way it works is that in making job assignments
	(for for doing what has been sold) availability is usually
	at least the second most important skill. (often comes in
	as number one.)