Product Support Strategy
Anthony Scott-Hodgetts
January 28, 1988
Within the Microcomputer Group, INMOS has collected a large number of talented and innovative individuals; we now face the problem of using this talent to produce the next generation of high quality products in an increasingly competitive world marketplace.
Clearly, the first stage is to conceive the architecture and design of those products. In general, INMOS has succeeded in this area, and we would expect similar success in the future. However, both during the development of products and after their initial market introduction we have failed to maintain the high standards required of a company desiring to establish itself as a world leader. Moreover, products lying outside the main arena have lacked architectural soundness, have been under-resourced during development, and due to poor integration between parts of MCD have appeared late and without the functionality of truly market worthy goods. It must be stressed that these failings are caused by factors largely outside the control of those performing the product development. Two significant, but related, factors impeding smooth progress are: lack of product strategy, that is, what should we aim to produce, when and why, and lack of suitable support structures to ensure that the development can proceed smoothly.
The purpose of this document is to explore the latter of these issues; it is divided into three further sections: a discussion of product support, a similar discussion of project support, and a conclusion.
INMOS is committed to growth by the continuing diversity of its products, whether silicon, subsystem, or software. Unfortunately, we cannot merely create the products, sell them to an unsuspecting world, and then run with the profits. Our products are not simple, nor perfect; our customers are often less than perfect themselves. There must be an organisation whose job it is to cope with these difficulties, an organisation which grows with the growth of our markets, in proportion to the needs of our customers. If we fail to resource this structure, we shall be perceived to be amateurish.
Our front line in both hardware and software product support is the Field Application Group. Problems, queries, bugs and the like which cannot be handled by the FAEs, either because of time pressure or complexity, will be passed on to Software Support. The Software Support Group has amongst its tasks the following two key functions: to be a focal point for communications about software from the user community, and to provide maintenance for existing software products. The maintenance, or evolution, of our software will not be performed by the Software Development Group which has, as its name implies, a different role to play in our success. As the number of different software products increases, so must the size of the Software Support Group: this is inevitable. Few people are happy with the support role as a career in itself, and we must ensure that the Software Support Group has a slow turnover of staff from other software related areas of the company. This is consonant with our general philosophy of allowing movement of personnel from project to project as required by individual interest, personal development, and company needs. The group currently consists of one person: Michael Poole, who is responsible for all aspects of support. The appearance of software products for the IBM, VAX and SUN will require a further person to join the group during the first half of 1988. From that point on, we should budget one extra person for every 2/3 major product releases; note that we shall often be supporting old versions of a product alongside later releases.
To some extent, the Central Applications Group has lacked direction recently, as its line of command spans different time zones. This has impaired its growth as a strategic arm of the company. We should recognise the importance of this group as a force both to grow our business and prove our products, and we should resource it accordingly.
Key tasks for the group should be:
We are currently operating on a one person to several projects basis. As the nature of Central Applications projects changes to match the significance of their aims, we shall be aiming at 2/3 people per major project. We should aim at an initial staff budget of at least eight people; this number should certainly double over the next two years as we see the positive feedback from their work.
It is a sign of corporate maturity to recognise the importance of clear, consistent product documentation. Customers seeing low quality, or confusingly presented documentation will feel that this must be a reflection of the overall product quality: the documentation must enhance our product not compromise its success.
The Documentation Group should operate as an editorial and publishing service for MCD. Stephen Zenith has already produced proposals relating to the future of the group, and this report supports his view that the structure of a successful Documentation Group should be of the form:
The scope of the group should be from initial attempts to lay out documentation by the project teams concerned, to the first production run of the finished documents. It is important to recognise the efficiency we gain by keeping this process under the control of a single, identifiable and accountable group.
INMOS provides training both to the end-user community and to consultancies providing their own training to that community. In the U.K. we have a very viable training programme in place; there are plans to expand the number of courses over the next year or so to cover such topics as software tools and the transputer instruction set. Given the active consultancy market outside INMOS, we probably require no more than 3/4 people in the Training Group U.K.
However, the U.S. presents a harder challenge: few academics are won over to either transputers or occam. Realistically, the Training Group should try to increase its U.K. business modestly, while pushing hard for U.S. acceptance. As a general rule, we should be budgeting 2 Training Group members for each INMOS outlet over the next two years.
Future product development will be on a strictly project oriented basis. Project staffing will concentrate on providing the necessary technical expertise to design and build the envisaged product. However, such teams cannot waste precious development time performing tasks which are peripheral to the main job. INMOS must, therefore, create a number of project support teams whose existence shall guarantee more economical use of project, that is, critical time.
The following teams should be provided well before significant projects are at the stage of requiring their services.
As Douglas Stevenson has directed, we should aim to introduce quality into our products at the earliest stage, by being quality oriented. The QA team could cover software alone, or the hardware/software mixture inherent in our subsystem products. In either case, we require at least two people to staff the QA group in the very near future. Their tasks would include:
INMOS has been guilty in the past of certain sins of omission. Generally, they have involved cross-disciplinary communication within MCD, with the result that on bringing together the various component parts of a potential product, the parts do not ’fit’ correctly. Clearly, the best answer is to have a sensible specification and design before building the prototype product. However, we do not live in a perfect world, and sometimes we cannot get it right first time. This does not imply that we should abandon hope of improvement: alongside the active endeavour to achieve good system design, we should set up a small group whose job it would be to ensure that the project team members keep the goal of final integration in mind. Also, there should be an independent body to perform product tests at the system level, those tests having been agreed in the product design phase(s). It does seem that INMOS has an aversion to formalising integration and testing, but all the work we do in these areas wins time on the critical path of a project.
Staffing for this group should be two people initially, rising with the number of projects as appropriate. It is difficult to produce a simple algorithm to determine a satisfactory level in this group, but by setting up the group, and monitoring its progress we should be in a better position to predict when further resource will be necessary. Like software support and QA, this is a rather thankless task, and a suitable policy of staff rotation should be affected.
To work with outside vendors in producing joint solutions, for example, Niche(!) or Caplin. Also, to stimulate companies like Microsoft to commit resource to transputer projects. This requires technical skills together with market awareness, and considerable powers of encouragement, and needs careful staffing.
Even with smoothly running projects, there will always be unpredictable problems needing attention. In addition, we often have high priority requests to do things for specific and always very important customers. By creating a small, possibly one person, task force to deal with these interruptions, we will save key people lots of valuable time.
Sadly, there will be a certain amount of very tedious administrative work associated with our development projects. I strongly recommend taking this seriously, by setting up the post of Project Administrator to be filled by a non-technical person with a great deal of patience. As with the technical task force, we could and have been able to get by without it, but the benefits of employing such a person would soon be apparent.
In this report, I have recommended certain staffing levels for existing groups, and the creation of a number of small tactical groups whose job it would be to ’oil the project wheels’. Indeed, every such person is an initial drain on our profits, but these groups would have specific aims and therefore definite measures of success. We can always reallocate the personnel involved in the case of proven failure. However, in the case of success, we achieve faster product-to-market times: we should be ready to invest a few extra people to reap much greater rewards.