A couple of decades ago I was developing two product ranges, one for decision support and the other for stock forecasting and inventory management. We were an application software business within a division of Datasolve. We had got the critical point where maintenance fees matched fixed costs. For a software products business this is a key turning point as you can now invest licence and implementation fees in the next generation of products. Utilisation models, normally used for software projects and consultancy in contrast are delivering to requirement so each project is journey with a beginning, a midland an end while developing an application product sabot a never ending journey. The culture and measurements are very different.

For a range of reasons we ended up in a Management Buyout (I was one of the 50) in which three companies with the Thorn EMI Software group merged and bought themselves out to create a new company DataSciences. The other main company, and dominant partner was Software Sciences who were a project based software house. As is the nature of things we were re-organised and I ended up reporting to a General Manager whose entire life had been managing a portfolio of high value long term defence projects. In contrast we were trying to invest in the next generation of project, running short term installations with license fees. My new boss had no idea what was going on. In a project environment you didn’t invest and you measured utilisation. Variations were negotiated with the client. In the product environment you invested, most of the staff were not externally utilised and there were expectations of user groups, marketing and the like of which he had no experience. I remember he came to a MUG (Murco User Group) in Swindon and in the after dinner speech told all of my users what a good project we had. He never understood how I made a profit and the idea I would invest that in a new development for which there was no RFI, no agreed client spec was alien. When we finally got the point across he put in a project manager to replace by experienced product manager and he wasted the whole budget into trying to write a requirements specification.

What has been fascinating is to realise that the distinction between the two is still problematic. Consultants, even when using software want to satisfy the client by doing ad hoc work for each implementation, rather than positioning that client need to allow the development of generic product. The idea of making to sell is client. Developing application software is a complex dance in which need and delivery co-evolve, its not a linear process. Using utility tools to provide short term function, rather than forcing development of long term capability is another common error or mistake. The need to maintain a personal relationship with the client takes precedence of developing the organisation’s market position and repeatable, scalable capability. There was a wonderful Video Arts film we used to show called Who sold you this then starring John Cleese which made the point well.

After several decades of living with this I suspect the problem is entrained, so I am learning to be stubborn. OK these days applications are assemblages of objects but the principle is the same – a lot of what you produce are black boxes that provide functionality that was not previously defined in detail if at all. Its not a series of stand alone events in which you may copy across things that you did before. That never scales.

Of course developing a software product/object that can be used in multiple contexts, including ones that have not been anticipated, costs a lot more that producing to a specific requirement. So development guys tend to look at the output and make claims such as I could write that in three months which is probably true if the output related to a single user meed. But that is not the case, but the point is almost impossible to make.

< Prev

Fidelity in complex systems consultancy

It been a week since my tirade against the abrogation of leadership by falling back ...

Category: ,

Further Posts

Next >

cum hoc ergo propter hoc

The fact that a rooster crows at sunrise does not mean it causes the sunset, ...


Further Posts