Fog Creek Software
Discussion Board


Your own words :
Consultingware is a variant of shrinkwrap which requires so much customization and installation that you need an army of consultants to install it, at outrageous cost. CRM and CMS packages often fall in this category. One gets the feeling that they don't actually do anything, they are just an excuse to get an army of consultants in the door billing at $300/hour. Although consultingware is disguised as shrinkwrap, the high cost of an implementation means this is really more like internal software.

I am a programmer for a small company that sells "consulting ware".
We do a retail mangement product ( point of sale,accounts receivable, payable,general ledeger, service,rental etc) that automates a retail business. We have customers from one store to many hundreds of stores. We have customers in a variety of retail niches. We have customers with a vast variety of business models.

We have grown and survived since the late eightys ( my time started in 1991 ) by making our software configurable enough to sell to people with a wide variety of needs.

The cost of this is that it does take a very knowledgable person, not just about the software but about the business the customer is in, to set up our software to meet the customers needs. A pharmacy is very differant from a cell phone store, comissions, speed versus negotiation etc.

It also requires more complicated support when the people using the software have a wide variety of jobs and levels of training.

Our costs are not outrageous, we give very good value.
( ;)

My point,  I don't think what we do could ever be shrinkwrap.
the big boys in my company ( i own a piece but i write code not business plans) dream of this and within specialised retail niches where the questions and answers are usually the same we come close., buit I know what make us work is being able to adapt to the way our customers do business.
Some of it is a obvious -  supplier chain automation etc  but a lotr of it isn't.

I am impressed by your writing because so much of what you say is an articulate description of various things that have kicked me in the face.

What advice do you have for a company like mine?

mike abbott
Tuesday, February 24, 2004

One problem with consultingware is that you can't increase your company's sales without increasing the staffing of consultants (or sales engineers, or whatever you call them.) This is not the end of the world by any stretch of the imagination, but it's a disadvantage compared to a company that sells off-the-shelf software that needs very little customization.

The other thing wrong is that a consultingware firm will always have a cost structure that's too high for small businesses and startup businesses. A new startup will always prefer to use the $500 shrinkwrap product even if they have to tailor their own processes to the product, rather than the $100,000 product that fits their needs like a glove -- because a new startup doesn't HAVE processes yet.

The story I like to tell is about Scitex and PageMaker. In 1984 the only way to put out a magazine digitally was with Scitex equipment, which cost $millions, a classic Consultingware company. When desktop publishing appeared Scitex laughed at it. PageMaker on the Mac could only do 4 page magazines and only in black and white! Where's the threat in that! They ignored their low-cost brethren until it was too late. Now virtually all publishing in the world is done on PCs with Quark Xpress and Scitex (merged with their onetime competitor Creo) is chasing after a smaller and smaller audience of very high end publishing clients that is rapidly vanishing.

Joel Spolsky
Fog Creek Software
Tuesday, February 24, 2004

I work for a company that sells consulting-ware. 

One client I worked with made it very clear that they wanted to get exactly the same software as everyone else.  I.e. for them, it was a "plus" that they got the same .exe files as everyone else, and only the "configuration" was different (considerably different as it happens).

However, it seems to me that "configuration" can be harder to maintain and debug than code. 

Clients seem to feel  secure in the fact that, except for "configuration", they have the same stuff as everyone else.  But I sometimes wonder if they'd be better off if they really did have different code (build on a shared library of course).

What do you think?

Wednesday, February 25, 2004

Having worked at a company that attempted separate codebases with some (poorly) shared libraries... and now working at a company that has one codebase with ever-growing configuration...

Well, the configuration way seems to work a lot better. We have to negotiate with customers a bit when new features are needed, but as long as everyone is reasonable it works.

Aaron Lawrence
Wednesday, February 25, 2004

Consulting-ware always has the disadvantage for the client that the tendency is to change the business to fit the software.

Oh yes it can have all the switches and twiddles you like but the more you switch and twiddle the more the 600-1000 quid a day consultancy  mounts up.

Consultancy-ware if it were a sound would be a sharp intake of breath followed by 'Welll, you could do that...'

Simon Lucy
Wednesday, February 25, 2004

> Consulting-ware always has the disadvantage for the client that the
> tendency is to change the business to fit the software.

*cough* SAP *cough*

Wednesday, February 25, 2004

I've never seen a good implementation of such BUT...

Consulting-ware has the ability to come with factory-set configuration and behave just like the shrink-wrapped software... it also has the benefit of changing IF YOU WANT TO (at cost of £xyz)

You can have FobBugz, which will only ever do what Joel decided you want, or you can have another product configured to emulate FobGubz out of the box without the future restrictions so you make it do what you actually want.

Now in my experience the out-of-the-box process solution is very poor. But it doesn't have to be.

If we're going to call configurable shrink-wrapped products Consulting-ware perhaps we should call the non-configurable shrink-wrapped products Fixed-ware or Arrogance-ware.

Wednesday, February 25, 2004

The "configuration isn't code" people are a bit strange.  Well, they're making some incorrect assumptions to work around their own business rules/processes, and I think they know that on some level.

We work with a client who has 'rigorous' time-consuming test periods for new .exe's, or new scripts, but not new configuration.  Thus there are people here who want to replace our VB scripting system with one of those hard to develop, not terribly useful automated scripting interfaces because that "isn't programming."  Because if we generate a config file, rather than something that is clearly code, they won't have to run it through change control.  I suggested stuffing the script text into a CDATA node in the XML, but no one took me seriously.  *sigh*

What no one wants to admit is that the supposed difference in stability between code and configuration only exists where the code has been tested carefully against a variety of configurations.  Have we ever run a test system set up differently from everyone in our user base?  We write consultingware.  That'd be a big fat NO.

Wednesday, February 25, 2004

The dirty secret about consultingware is that the consultants often implement one-off solutions.  Then the next release ships, and the API is mostly still there, but some methods have been deprecated and/or have changed subtlely.  Or maybe they used undocumented methods.  So they're stuck, and the company loses an upgrade sale.  Maybe the customers are hoping that if it's "just configuration", the configuration will be upgradable.

Saturday, February 28, 2004

*  Recent Topics

*  Fog Creek Home